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: Fri, 21 Aug 2015 07:49:05 +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>
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