This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Update on commit and release workflow discussions

On Tue, 18 Aug 2015, Siddhesh Poyarekar wrote:

> We could do this using empty commits of the form:
>     Reopen bug #bznumber
>     Not-Resolved: #bznumber

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 
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.)

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 

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.

> or even to fix up ChangeLog entries like so:
>     Fix up commit id <commit id>
>     ChangeLog:
> 	    <the fixed up changelog>
> similarly to add missing attributions.

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.

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

Joseph S. Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]