On Tue, Apr 3, 2012 at 4:29 PM, Brion Vibber <br...@wikimedia.org> wrote: > One thing I've noticed in the last couple of days of madly reviewing things > in gerrit is that merge conflicts in the RELEASE-NOTES-1.20 file are very > common. > > Because of the delay between submission and post-review merge, there's a > high probability that a new entry in one of the sections of > RELEASE-NOTES-1.20 will "conflict" with entries added by other commits that > have been merged in the meantime. Git doesn't understand that it can just > slip the line in at the end of the section, alas. :) >
Yeah. That was a problem in SVN and it's a problem in Git now too. The only difference was with SVN you had to fix the problem yourself before committing, whereas now you don't know until you attempt the merge. It's part of the fun ;-) > Do we really need to be maintaining these release notes files this way, > though? > > Now that we have pre-commit review, we can more aggressively police commit > messages so that the first line is more consistently "release-notes-ready", > and we can generate release-notes files from commit logs instead, and avoid > the make-work of manually adding to and merging RELEASE-NOTES files on > every change. > > Thoughts? Concerns? Threats? :) > I like the idea in principle--it certainly will help reduce the number of silly conflicts we're stuck rebasing. The only thing I'd worry about is making sure that we enforce proper commit summary guidelines. I'd be interested in seeing what the results roughly look like--I imagine it'd still need some manual wrangling before we publish them as final. In fact--you could submit the proposed release notes to the branch around the time we cut the first beta/rc, and they can be discussed/formatted/bikeshedded on gerrit. -Chad _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
