On Thu, 07 Nov 2013 19:29:06 +0100, C. Scott Ananian <[email protected]>
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/mediawikireleasenotes-driver-installer.sh
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=418149
[3] http://i.imgur.com/OmFyFbi.png
--
Matma Rex
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
