This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: List of fixed bugs in NEWS now automatically generated
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Thu, 5 Nov 2015 23:35:34 +0000
- Subject: Re: List of fixed bugs in NEWS now automatically generated
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1511052229290 dot 8571 at digraph dot polyomino dot org dot uk> <20151105230432 dot 305A22C3B4C at topped-with-meat dot com> <alpine dot DEB dot 2 dot 10 dot 1511052315270 dot 8571 at digraph dot polyomino dot org dot uk> <20151105232432 dot E6FDE2C3B40 at topped-with-meat dot com>
On Thu, 5 Nov 2015, Roland McGrath wrote:
> I think we want conventions whereby one can tell from bugzilla alone which
> release branches have a particular bug fixed. That seems desireable just
> for people (whether maintainers or not) trying to figure things out. A
> concrete benefit would be that it becomes possible to fully automate the
> process of updating NEWS on a release branch, which I think is less
> error-prone than relying on manual updates. Eventually, we could even have
> a git hook that enforces that canonical NEWS updates are included in each
> commit to a release branch.
I'm fine with having such conventions, hooks etc. if someone wishes to
implement them. Though I think the utility is substantially less than (a)
a system / conventions for automatic ChangeLog generation from commit logs
(with a hook to stop commits to master / release branches that don't
follow that convention unless explicitly marked as deliberately having no
ChangeLog entry) and (b) a notation for commit messages that causes a git
hook, if the commit is on master, to mark a bug as FIXED with the next
mainline release as milestone. Since (a) and (b) are both relevant to a
lot more commits than anything specific to release branches (and once we
have (a), it becomes possible to compare the git-patch-id of mainline
commits with that of patch postings, and so to mark many patches in
patchwork as committed automatically).
--
Joseph S. Myers
joseph@codesourcery.com