Update on commit and release workflow discussions

[Siddhesh Poyarekar]

On Mon, Aug 17, 2015 at 07:53:46PM +0000, Joseph Myers wrote:
> An advantage of extracting the fixed bug list from Bugzilla at release 
> time is that you don't have any commits associated with such fixes (unless 

Agreed.

> the correction is after the fixed bug list was put in NEWS), just changes 
> to Bugzilla data (which seems to be the logical place to fix such things).  
> A disadvantage is the need for an extra Bugzilla field to list fixed 
> versions, but it should be easy to add a field for a plain text 
> space-separated list of fixed versions.  (Or if you want to use milestones 
> as much as possible, say the milestone is for the main fixed version and 
> the new field is "Backported fix in" or similar.  In any case, the commit 
> hook should update this field when marking the bug fixed.)

I like the "Backported to" field along with the milestones field for
the main fix.

> Given such a field, the bug-listing script would search for bugs with a 
> resolution of FIXED and the relevant version in the list of fixed 
> versions.
> 
> Although annotations such as the above could be used to reopen bugs in the 
> case of reverting a fix, that may not be common enough to be worth having 
> the annotation support instead of simply reopening the bug manually.

Fair enough.

> gitlog-to-changelog supports a file (which presumably would be checked in) 
> listing amendments.  The obvious alternative would be: if you want to do 
> an amendment, then (a) run the ChangeLog generation script and check in 
> the results (in the same commit as updating where that script says what 
> the newest commit covered by the checked-in ChangeLog is, so only 
> subsequent commits are included the next time gitlog-to-changelog is run), 
> (b) edit ChangeLog and check in those edits.

I vaguely remember someone (Roland?) not being in favour of generating
the ChangeLog at any time except during release.  I am inclined
towards generating ChangeLogs to fix them up because it does not
involve yet another layer of metadata.

> There should probably be a way to say that a particular commit does not 
> get a ChangeLog entry, rather than commits without something marked as a 
> ChangeLog entry quietly defaulting to not having one.  Maybe No-ChangeLog: 
> in the commit message (and reject the push if a commit to master or a 
> release branch doesn't have either ChangeLog: or No-ChangeLog:).

Makes sense.

So what we have now is:

Everything I suggested in the OP
 + Bug list in a more descriptive format
 + Get fixed bugs list using the milestones field
 - Acked-by: tag since it is not directly useful

I've set aside the ChangeLog edits question to know if the objection
to generating and editing ChangeLogs between releases.

Siddhesh