If this drives you barking mad too, fix it. Should be doable by injecting a bit of code here:
http://git.wikimedia.org/blob/integration%2Fzuul.git/ac3ba4fe9f9dace5673a653...
I will personally build a statue in your honor
--- Ori Livneh ori@wikimedia.org
I recall someone on IRC (Bartosz or Tyler?) saying they have a python (?) script to make this work in their local repo, but not knowing how to get it in the server.
On Tue, Nov 5, 2013 at 9:45 PM, Ori Livneh ori@wikimedia.org wrote:
If this drives you barking mad too, fix it. Should be doable by injecting a bit of code here:
http://git.wikimedia.org/blob/integration%2Fzuul.git/ac3ba4fe9f9dace5673a653...
I will personally build a statue in your honor
Ori Livneh ori@wikimedia.org
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Nov 5, 2013 at 12:49 PM, Siebrand Mazeland (WMF) smazeland@wikimedia.org wrote:
I recall someone on IRC (Bartosz or Tyler?) saying they have a python (?) script to make this work in their local repo, but not knowing how to get it in the server.
That's Bartosz's tool: https://github.com/MatmaRex/mediawikireleasenotes-driver It's great, yep. But it'd still be nice to have Jenkins handle it.
Le 05/11/13 21:45, Ori Livneh a écrit :
If this drives you barking mad too, fix it. Should be doable by injecting a bit of code here:
http://git.wikimedia.org/blob/integration%2Fzuul.git/ac3ba4fe9f9dace5673a653...
I will personally build a statue in your honor
We could surely add a feature in Zuul that would let us ignore conflicts for some files. That should be possible by defining a merge driver using the "ours" strategy and then apply that driver in /.gitattributes for the RELEASE-NOTES* files.
A side effect is that the gate-and-submit jobs would work properly but Gerrit would end up refusing to submit the patchset because it cant merge it :-/
So that would merely delay the conflict resolution to post +2 which is even more annoying.
On Wed, 06 Nov 2013 09:40:59 +0100, Antoine Musso hashar+wmf@free.fr wrote:
We could surely add a feature in Zuul that would let us ignore conflicts for some files. That should be possible by defining a merge driver using the "ours" strategy and then apply that driver in /.gitattributes for the RELEASE-NOTES* files.
You could probably use my driver for this (linked in earlier post, also [1]), which does some mostly meaningful checks to decide if the release notes are mergeable.
A side effect is that the gate-and-submit jobs would work properly but Gerrit would end up refusing to submit the patchset because it cant merge it :-/
Yeah… JGit (which is what gerrit uses instead of git) does also supports merge drivers (or so says its documentation), it can't possibly be very hard to set one up – someone would just have to reimplement the algorithm in Java.
Or maybe we could have another bot to rebase using my driver before gate-and-submit runs. But personally I have no idea if/how it could be implemented; Antoine?
[1] https://github.com/MatmaRex/mediawikireleasenotes-driver
Could we do an end run around to fix this? For example add a
Release-Notes: this text shows up in the release notes
field to the commit. Before release branching, some slightly-fancier variant of "git log | egrep '^Release-Notes:'" gets run to automatically populate the release notes with the appropriate information. Then we don't have to fiddle with the merge algorithm. --scott
On Wed, Nov 6, 2013 at 4:43 AM, Bartosz Dziewoński matma.rex@gmail.comwrote:
On Wed, 06 Nov 2013 09:40:59 +0100, Antoine Musso hashar+wmf@free.fr wrote:
We could surely add a feature in Zuul that would let us ignore conflicts
for some files. That should be possible by defining a merge driver using the "ours" strategy and then apply that driver in /.gitattributes for the RELEASE-NOTES* files.
You could probably use my driver for this (linked in earlier post, also [1]), which does some mostly meaningful checks to decide if the release notes are mergeable.
A side effect is that the gate-and-submit jobs would work properly but
Gerrit would end up refusing to submit the patchset because it cant merge it :-/
Yeah… JGit (which is what gerrit uses instead of git) does also supports merge drivers (or so says its documentation), it can't possibly be very hard to set one up – someone would just have to reimplement the algorithm in Java.
Or maybe we could have another bot to rebase using my driver before gate-and-submit runs. But personally I have no idea if/how it could be implemented; Antoine?
[1] https://github.com/MatmaRex/mediawikireleasenotes-driver
-- Matma Rex
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, 07 Nov 2013 19:03:33 +0100, C. Scott Ananian cananian@wikimedia.org wrote:
Could we do an end run around to fix this? For example add a Release-Notes: this text shows up in the release notes field to the commit. Before release branching, some slightly-fancier variant of "git log | egrep '^Release-Notes:'" gets run to automatically populate the release notes with the appropriate information. Then we don't have to fiddle with the merge algorithm. --scott
https://www.mediawiki.org/wiki/Requests_for_comment/Release_notes_automation
Merge drivers aren't nothing exceptionally fancy, and it wouldn't require much fiddling (I've already written the code that does the work and been using it since, it's perfect). But we need someone with access to appropriate parts of the infrastructure to set it up for gerrit/Jenkins, and I don't have it.
On Thu, Nov 7, 2013 at 1:16 PM, Bartosz Dziewoński matma.rex@gmail.comwrote:
On Thu, 07 Nov 2013 19:03:33 +0100, C. Scott Ananian < cananian@wikimedia.org> wrote:
Could we do an end run around to fix this? For example add a
Release-Notes: this text shows up in the release notes field to the commit. Before release branching, some slightly-fancier variant of "git log | egrep '^Release-Notes:'" gets run to automatically populate the release notes with the appropriate information. Then we don't have to fiddle with the merge algorithm. --scott
https://www.mediawiki.org/wiki/Requests_for_comment/ Release_notes_automation
Both those proposals seem good to me. I'll add that "non-noteworthy commits" can always be marked in the commit message (an explicit 'Release-Notes: no' field, or [NOREL] in the subject or somewhere in the body, etc etc). That should further reduce the amount of manual release notes editing.
Merge drivers aren't nothing exceptionally fancy, and it wouldn't require much fiddling (I've already written the code that does the work and been using it since, it's perfect). But we need someone with access to appropriate parts of the infrastructure to set it up for gerrit/Jenkins, and I don't have it.
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... --scott
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
wikitech-l@lists.wikimedia.org