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: Roland McGrath <roland at hack dot frob 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
- Date: Tue, 8 Sep 2015 14:49:13 -0700 (PDT)
- 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>
> 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.
I don't really understand the second sentence.
My position on this is simply that amending logs is not worthwhile enough
to merit any nontrivial complications to the machinery or workflow. I'd
rather start with a system that is as simple as possible, and only worry
about log amendments if and when we have a concrete occasion of someone
feeling very strongly that a particular log entry needs amending.
My other general comment is just incrementalism. The thing that is most
straightforward and has clearest consensus is automating the fixed-bugs
list for NEWS. So I'd like to see these steps completed before we commit
(level of pun intention left as an exercise to the reader) to details of
other new plans:
1. Choose Bugzilla conventions for tracking fixedness and distinguishing
fixed on trunk from fixed on a given release branch.
2. Write and test a script that generates a pretty list for a NEWS file by
doing a Bugzilla query.
3. Agree roughly on the release-time process that should be used to put the
list in the file.
4. Remove existing list from top of trunk NEWS file.
5. Do something appropriate to NEWS files of release branches still active.
Of course the discussion about commit log formats, git hook behaviors
driven by log entry contents, and ChangeLog generation, can continue in
parallel. But I'm not going to think very much about those details, nor
consider discussion of any such things to have reached real consensus,
until after we have completed the steps above and begun adapting to the
workflow changes just for that.
Thanks,
Roland