On Fri, Mar 1, 2013 at 2:20 PM, Jon Robson <jdlrobson(a)gmail.com> wrote: +1, also useful for release notes. Could the footer line be auto-generated for indexing purposes? Yay for bikeshed topics ;-) -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

Well, that's true if you're only building release notes by copy+pasting the first line. If it's scripted, it's trivial to pull the bug # from the footer as well. And no, commit messages cannot be auto-generated by Gerrit, as that changes the sha1. -Chad On Fri, Mar 1, 2013 at 2:23 PM, Erik Moeller <erik(a)wikimedia.org> wrote:

Le 01/03/13 14:37, Yuri Astrakhan wrote: So instead of us just writing to the RELEASE-NOTES we will instead have to pass commands to yet another unstable bot that will do it for us? What is the added values beside adding overhead to the process? -- Antoine "hashar" Musso

What's the issue with a bot appending a few lines to a release-notes section if it sees it the commit message? But yes, release-notes conflicts are a major pain and kills the streamlined patching workflow - submit->review->merge, frequently requiring extra "->fix->review" steps right before merge. Might not work well with so many committers and no strict central project management. It will become a big burden to go through all commits and pull out all relevant release-notes (actually doing what the bot will be doing, only in a non-automated fashion because the commit messages won't be as structured). But if someone is willing to do that... sure, why not :)

it has to be implemented in java in order to work with the gerrit server (at least that's what i was told). Implementing a core gerrit feature like that might be a bit more resource intensive than having a simple bot... (?)

On Mon, 04 Mar 2013 17:03:58 +0100, Tim Landscheidt <tim(a)tim-landscheidt.de> wrote: Please go ahead if you think it's worth it. I didn't because in general I deemed the result not good enough, and when the automatic merge fails, you lose the information about branches being merged (try it). I can't imagine a setup where it wouldn't just work (other than you not running the installer inside a .git directory). And sharing the file + instructions insted of the installer is a big can of worms. (Where do you store the .rb driver file? Where do you add the entry for merging RELEASE-NOTES? Which config do you edit? How? git has a lot of options for all these things...) -- Matma Rex

On Sat, 02 Mar 2013 21:17:29 +0100, Tim Landscheidt <tim(a)tim-landscheidt.de> wrote: I wrote a very simple one some time ago, in Ruby. https://github.com/MatmaRex/mediawikireleasenotes-driver It doesn't really work. There are enough changes that are not simple additions that it solves no more than about 30% conflics for me. Maybe that rate could be improved using, like, a real algorithm for merging; but the naive solution doesn't really work. -- Matma Rex

On 02/03/13 19:13, Bartosz Dziewoński wrote: You would at least need some release-notes marker added by the commiter so that you can skip non-RL-worthy ones.

On Fri, Mar 1, 2013 at 2:59 PM, Daniel Friesen <daniel(a)nadir-seen-fire.com> wrote: No, Gerrit cannot detect these in the header. Also, this is pretty standard Git-fu to include this sort of metadata in the footer of the commit. -Chad

"Daniel Friesen" <daniel(a)nadir-seen-fire.com> wrote: *Argl* :-) May I repeat my question from http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/66432: | Is there another software project that uses the summary line | in a similar way to MediaWiki? Tim

On 2013-03-03 9:36 PM, "Quim Gil" <qgil(a)wikimedia.org> wrote: [...] still you are supposed to explain in each commit message what you are doing in that commit I don't see that as being an issue. If anything its an argument for putting bug number in header. You can't say (part 1/2 bug XXXX) in a footer line. [...] >> Is there another software project that uses the summary line >> in a similar way to MediaWiki? > That was the best question of this thread. I have done some research, and the guidelines I found mentioning the inclusion of bug numbers in commit messages pointed all to a specific bug line after the commit description and an empty line - which is in line with our guidelines. Gerrit and other Git tools understand that line as metadata and you can do good things with it (as we are on our way of doing between Gerrit and Bugzilla): [...] If all the other open source projects jumped off a bridge... ;-) Personally I prefer it in the first line. Second to a good one line summary of what was done, the bug number is the next most important thing. It allows one to see the context the commit was made in. Having it in the first line allows one to find it easily and have it displayed in various "one line" log formats ( including in gerrit when you get a list of commits) The primary argument for changing the format is so gerrit can index it. Beyond the /sounds like a gerrit problem/ argument presented previously, I would additionally argue that that is not that useful a feature. (Even if on the surface it sounds cool). Any commit fixing a bug should be listed on the bug. If I have the bug number I can just look at the bug to find the relavent commits. That said, at the end of the day I don't think it really matters much either way. --bawolff _______________________________________________

FWIW, I also prefer to have those 10 extra characters in the header. Also, when I'm scanning the git shortlog, I don't give a damn about bug numbers, because if I care enough about a commit to want to check its bug report, it's very likely I'm already looking at the full commit message anyway. But that's just my opinion. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo(a)gmail.com

On Mon, Mar 4, 2013 at 7:06 AM, Quim Gil <qgil(a)wikimedia.org> wrote: I like to know about the problem before the solution implemented, that saves me some time to think what solutions could be possible. But that doesn't mean it always have to be in the header. It matters from the point of view, looking like a bug fixer you are more concerned with bug numbers while other people are concerned about what is implemented. But what I find more important is see the bug numbers in the Gerrit 'view', its easy to find the change for a particular bug being solved. Having a separate column (as Erik suggested) for that would be the best solution :) -- Cheers, Nischay Nahata nischayn22.in

On 20/03/13 11:59, Niklas Laxström wrote: The "stored things" are set in gerrit config.