This is the mail archive of the libc-alpha@sourceware.org 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 Mon, 17 Aug 2015, Siddhesh Poyarekar wrote:

> Apologies for taking so long to send this.  Based on discussions on
> the list and then following up on that in the glibc BoF at the
> Cauldron, I have made a draft of what our new commit and release

Will someone post detailed notes (and video?) from the BoF?

>   - The email should also have the necessary 'Signed-off-by:' fields
>     to give credit to all authors contributing to the patch.  Figure

That seems to duplicate having the ChangeLog entry there, if the ChangeLog 
entry includes all the author lines.

> - Reviewer: reviews the patch and acks it by appending an 'Acked-by: '
>   to the response.

What does Acked-by mean (given that the goal is consensus, which someone 
liking the patch may or may not mean, and there are lots of ways of 
commenting on a patch short of saying that someone thinks the whole patch, 
with or without further changes, is ready to go in)?

> - Committer: adds the 'Acked-by:' in addition to the Signed-off-by's
>   and pushes the change, editing the commit description as necessary.

I don't see the use of that annotation in the commit message.  It's not 
something that would be automatically processed in any way (unlike the 
ChangeLog: entry and details of fixed bugs).

> - Release manager:
> 
>   - Runs a script to generate ChangeLog file and fixes up the
>     ChangeLog file for any errors
>   - Script generates bug numbers based on the ChangeLog fields

A list giving the summary line of each bug rather than just the number 
would be better, as suggested in 
<https://sourceware.org/ml/libc-alpha/2015-08/msg00103.html>.  You can use 
the REST API (see <http://bugzilla.readthedocs.org/en/latest/api/>) to get 
bug information in JSON format, e.g. 
<https://sourceware.org/bugzilla/rest.cgi/bug/18681> (so once you have a 
list of bug numbers, getting summary lines for them all is easy).

>   - Script closes bugs in the bugzilla based on the generated bug list

I think bugs should be closed when the bug fix is checked in (this makes 
Bugzilla a lot more readily useful to find unfixed issues to work on), not 
at release time - that is, bug closing should be based on a tag in the 
commit message (*not* the [BZ #N] in the ChangeLog entry, unless we make 
that "[BZ #N fixed]" or similar to indicate the commit is meant as a 
complete fix for the bug).  And we need a way to avoid listing as fixed 
bugs that got reopened / where the patch got reverted.

(I'd prefer bug closing from the commit hooks rather than from a cron job 
running every few minutes, although if closing from hooks is difficult 
then a cron job isn't that bad.)

-- 
Joseph S. Myers
joseph@codesourcery.com


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