On Thu, 07 Nov 2013 19:29:06 +0100, C. Scott Ananian cananian@wikimedia.org wrote:
I thought the main problem there was that gerrit/Jenkins would still block the merge, even with a custom merge driver. But if that's not the case, then yes making edited RELEASE-NOTES Just Work is even simpler (maybe not better?). But I don't have the necessary access either...
There are two parts to the problem: 1) jenkins voting V-1 because it can't merge the change – would be trivially alleviated by installing the merge driver on it, since it uses the standard git implementation for everything. Depending how it is setup: * If it reuses one git repo, somebody would just have to copy the driver file and set some config options once. * If it creates new repos all the time, the setup would have to be made into a script – my driver actually comes as such "installer" script [1] which just needs to be run in the repo directory and then Just Works.
2) gerrit not being able to merge the changes. We can't just install the driver, because it uses JGit (a git implementation in Java). We could do two things here too: * Rewrite my merge plugin in Java to work with JGit, once it's made to support them. This is apparently ongoing work [2], I'm sure they'd be happy to receive help. * Have jenkins rebase each change as part of the gate-and-submit pipeline using the merge driver we installed on it per 1). This would also make the history graph prettier by getting rid of merge commits (the graph currently looks like [3]…), which I've heard Chad in particular wants very much.
This really isn't insurmountable, but nobody who is able to do any of these things seems to care :(
[1] https://github.com/MatmaRex/mediawikireleasenotes-driver/blob/master/mediawi... [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=418149 [3] http://i.imgur.com/OmFyFbi.png