Making WordPress.org

Opened 6 years ago

Last modified 3 years ago

#3867 new enhancement

Refreshing Core Patches

Reported by: pento's profile pento Owned by:
Milestone: Priority: normal
Component: Trac Keywords:
Cc:

Description

There are a lot of patches on core tickets that no longer apply cleanly, particularly after the various code formatting commits. To help make these patches easier to work with, it'd be nice to have a button on attachments that folks could click to have a refreshed version of the patch created.

Having a button to run a job is preferable to automatically running across all tickets for a couple of reasons:

  • There will be more reformatting commits in the future, so having to run this on all tickets every time causes a lot of unnecessary ticket updates.
  • While it's pretty good, such a job can never be perfect. The output needs to be checked by someone who's actively interested in it.

Attachments (1)

patch-upgrader.php (9.1 KB) - added by pento 6 years ago.
Experimental patch refresher script

Download all attachments as: .zip

Change History (2)

@pento
6 years ago

Experimental patch refresher script

#1 @pento
6 years ago

patch-upgrader.php is an experiment in the viability of this approach. It should be run from a git checkout of WordPress, and expects a directory called "working" to exist in the same parent directory as the checkout, for it to store output.

It’s currently fairly restrictive, it only processes tickets where the newest patch was last updated before the first big reformat (2017-12-01), and only tries applying them to trunk as it was just before the first big reformat.

Running through them oldest to newest, in the first 500 tickets processed:

  • 425 of them had their newest patch uploaded before 2017-12-01.
  • The script was able to refresh patches for 52 of them.
  • With a quick visual inspection, 49 of them are correct, 2 have minor errors, 1 is clearly incorrect.

Removing the restrictions will hopefully increase the number of patches that can be refreshed, though I don’t know what effect that will have on the accuracy: the more times we have to fast forward through version history, the more opportunity there is for mistakes to happen.

Note: See TracTickets for help on using tickets.