On Tue, 03 Apr 2012 13:29:44 -0700, Brion Vibber brion@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. :)
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? :)
-- brion
We have a policy of restricting the length of the first line. Since it's used by gerrit as email subjects. So as a result when I write the first line of a git commit I inevitably leave out critical information. So the first line of a commit misses out information that if I had a RELEASE-NOTES line to write would be in there.
Also, I've noticed that a decent portion of my commits are small backend stuff or modifications. Stuff which have little business being inside RELEASE-NOTES. Frankly if we do it that way RELEASE-NOTES becomes little more than a commit log, which is a lot less valuable than the RELEASE-NOTES we currently have.