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: Siddhesh Poyarekar <siddhesh at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org, carlos at redhat dot com, roland at hack dot frob dot com
- Date: Tue, 8 Sep 2015 13:56:37 +0530
- 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> <alpine dot DEB dot 2 dot 10 dot 1508171441030 dot 29836 at digraph dot polyomino dot org dot uk> <20150817171102 dot GD2415 at spoyarek dot pnq dot redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1508171720590 dot 29836 at digraph dot polyomino dot org dot uk> <20150817193536 dot GE2415 at spoyarek dot pnq dot redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1508171940480 dot 24954 at digraph dot polyomino dot org dot uk> <20150821021905 dot GQ2415 at spoyarek dot pnq dot redhat dot com>
Ping?
On Fri, Aug 21, 2015 at 07:49:05AM +0530, Siddhesh Poyarekar wrote:
> 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