On Tue, 03 Apr 2012 13:29:44 -0700, 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. :)
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.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
