This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Hash out a solution for ChangeLog/NEWS at the Cauldron?
- 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: Tue, 4 Aug 2015 17:59:27 +0000
- Subject: Re: Hash out a solution for ChangeLog/NEWS at the Cauldron?
- Authentication-results: sourceware.org; auth=none
- References: <20150804173912 dot GC2504 at spoyarek dot pnq dot redhat dot com>
On Tue, 4 Aug 2015, Siddhesh Poyarekar wrote:
> I don't know how many of us are going to be at the Cauldron this
I won't be at the Cauldron.
> patches? We're at an almost perfect position with development frozen
> (we could keep it frozen for a week till we sort this out so that we
I don't think we should keep development frozen for such a purpose. If we
develop new tools that are most conveniently used from the start of a
release cycle (and I don't see why tools should depend on when you start
using them), then start using them after 2.23. I expect a significant
amount of work would be needed to develop appropriate tools, rework the
process for building releases etc. and make sure that the tools don't lose
flexibility; a week is hardly realistic.
> What I'm thinking of is a policy that'll allow us to auto-generate
> ChangeLog and NEWS from commit data so that whatever is posted on the
> list can be git-am'd directly and merged into master without rewriting
> the commit. This will allow for tighter integration with patchwork,
I think it's very unlikely casual contributors will get the formatting
details right (and for contributors with write access, being able to
git-am is irrelevant in many cases because either the patch is committed
before sending or changes at least to the commit message are likely before
commit).
> Acked-by too). The ChangeLog entry can be identified with a
> ChangeLog: tag. Likewise, we could have a NEWS: tag to identify NEWS
> items for the release and a BUGS: tag to include bugs that this commit
> resolves.
I think normal NEWS items for significant changes (as opposed to the list
of fixed bugs) are most appropriately handled through the
version-controlled text file rather than special processing of commit logs
(and the patch to NEWS should be included in the patch proposing such a
significant change, but if not included, can always go in a later patch).
This allows for easy editing, reordering etc. - while any system for
automatic processing of commit logs needs to allow for arbitrary mistakes
in those logs to be corrected when generating ChangeLogs and lists of
fixed bugs, it's inevitably more cumbersome than simply editing the NEWS
file directly.
> With this in place, the patch committer should take care to never
> rebase the patch into master and instead 'merge' it in to preserve
> history. Alternatively, (s)he could ask the submitter to rebase and
> provide a patch.
I don't understand what's suggested here. I don't find merge commits on
master useful for normal changes (and if you generate the ChangeLog
entries automatically from commit messages, and the list of fixed bugs
either from those or from Bugzilla, then actual merge conflicts should be
rare) - I prefer the linear history. (There might be exceptional cases of
development branches where merge commits are helpful, but not for normal
small incremental glibc patches.)
I would be happy to eliminate use of the separate libidn/ChangeLog and
localedata/ChangeLog to simplify ChangeLog generation (or indeed even
without automatic ChangeLog generation).
--
Joseph S. Myers
joseph@codesourcery.com