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: "Tulio Magno Quites Machado Filho" <tuliom at linux dot vnet dot ibm dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: Joseph Myers <joseph at codesourcery dot com>, libc-alpha at sourceware dot org, carlos at redhat dot com, roland at hack dot frob dot com
- Cc:
- Date: Tue, 08 Sep 2015 15:18:41 -0300
- 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> <20150908082637 dot GE11369 at spoyarek dot pnq dot redhat dot com>
Siddhesh Poyarekar <siddhesh@redhat.com> writes:
> 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.
It looks very good to me.
--
Tulio Magno