I like the idea of not having to mess with RELEASE-NOTES-#.## merge conflicts. But I'm not entirely sure about everything in the proposal.
On Thu, May 2, 2013 at 12:30 PM, Krinkle <[email protected]> wrote: > For more details see Proposal 2 on this page: > > https://www.mediawiki.org/wiki/Requests_for_comment/Release_notes_automation#Proposal_2:_Proper_commit_message >> To avoid wrong entries for bugs that were merely mentioned in the commit >> message but not fixed in that commit, it becomes more important that we >> enforce a consistent format. "bug 123" is a mention. "Bug: 123" in footer >> meta-data indicates the bug was fixed. So we're changing the semantics of that "Bug" footer already? Instead of being used for searching changesets related to a bug, now it's only for searching changesets actually fixing a bug? And what about changesets that only partially fix a bug? Or bugs where changes to both core and extensions are needed to fix a bug? >> We can't use the commit message subject because they aren't always the same >> as what you want to write in the release notes. So are we getting rid of the recommended less-than-50-character limit on commit subjects? Or are we assuming that whoever volunteers to clean up the subject-dump will expand on it as necessary? >> Mark entries with the relevant labels ("New", "Removed", "Breaking" etc.) I worry that whoever is doing this for API changes (if it doesn't wind up being me) won't know how we determine "Breaking" for API changes. I.e. "anything that's not backwards-compatible for API users". _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
