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? :)

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 _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l