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 19:53:46 +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> <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>
On Tue, 18 Aug 2015, Siddhesh Poyarekar wrote:
> We could do this using empty commits of the form:
>
> Reopen bug #bznumber
>
> Not-Resolved: #bznumber
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
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.)
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.
> or even to fix up ChangeLog entries like so:
>
> Fix up commit id <commit id>
>
> ChangeLog:
>
> <the fixed up changelog>
>
> similarly to add missing attributions.
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.
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:).
--
Joseph S. Myers
joseph@codesourcery.com