Re: Update on commit and release workflow discussions

[Siddhesh Poyarekar <siddhesh at redhat dot com>]

On Mon, Aug 17, 2015 at 03:00:51PM +0000, Joseph Myers wrote:
> 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?

I believe the video will be made available on the wiki page.  I did
not take detailed notes; I only took the responsibility of posting a
summary of this bit of the BoF.  I may write a blog post some time
this week so if nobody else has taken notes, I could post a link to my
blog post on the list.

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

Sorry, I should have mentioned that I envisioned the ChangeLog entry
as just being the list of files changed, not the heading line,
i.e. the date and authors list.  We did not explicitly discuss this at
the BoF though.

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

Acked-by means that the person thinks that the whole patch with or
without further changes is ready to go in.  There are indeed lots of
ways of commenting on a patch short of giving ones approval, but even
today we don't regard such comments as a green signal for a commit.
An explicit 'looks good to me' or equivalent is 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).

Right, it is just additional information that we won't currently use.
I don't mind withdrawing that (since it was my suggestion in the first
place) and considering it again if we ever decide that reviewer
information is useful.

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

Agreed.  We did not discuss the format of the bug list but this
suggestion was made on list earlier and nobody seemed to oppose that.

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

OK, so 'Resolves:' to indicate that a bug has been fixed and the bz can
be closed?  Then we don't have to depend on the ChangeLog [BZ #] at all.

So here's what I have so far:

Everything I suggested in the OP
 + Resolves: tag to indicate bugs that were fixed
 + Bug list in a more descriptive format
 - Acked-by: tag since it is not directly useful

Siddhesh