This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Update on commit and release workflow discussions
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: <libc-alpha at sourceware dot org>, <carlos at redhat dot com>, <roland at hack dot frob dot com>
- Date: Mon, 17 Aug 2015 15:00:51 +0000
- Subject: Re: Update on commit and release workflow discussions
- Authentication-results: sourceware.org; auth=none
- References: <20150817115747 dot GC2415 at spoyarek dot pnq dot redhat dot com>
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