This is the mail archive of the
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: Wed, 5 Aug 2015 11:09:55 +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> <alpine dot DEB dot 2 dot 10 dot 1508041743390 dot 10621 at digraph dot polyomino dot org dot uk> <20150805002648 dot GE2504 at spoyarek dot pnq dot redhat dot com>
On Wed, 5 Aug 2015, Siddhesh Poyarekar wrote:
> On Tue, Aug 04, 2015 at 05:59:27PM +0000, Joseph Myers wrote:
> > 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.
> Tools development before we adopt the new workflow implies that we
> keep the generated ChangeLog and NEWS files updated with each commit;
No, only that the commit message format and tools should be developed and
adopted together - a stricter format is only justified by having the tools
that use it, and the tools are the best way of telling whether oddities in
a particular commit message are actually problematic and need an
> I did not imply that. They need to be ready by the time the next
> release happens and that I can take responsibility for. So the week
Will you take responsibility for watching commit messages for each commit
on master and pointing out to people where they get things wrong and doing
the fix-ups needed for such mistakes? (I expect lots of fix-ups to be
needed at first, fewer later.)
> either, but we live with it. We can figure out a way to adjust for
> it; one idea would be for the committer to post a [committed] patch in
> such cases. A bigger worry is someone accidentally pushing a patch
I don't see the point in a [committed] message if only the log message has
> 2. Committer asks submitter to resubmit patch such that it applies
> cleanly to master.
> glibc is not as fast moving, so option 2 seems better. I think you
> like (2) better as well since it will produce a linear, clean history
> without the merge commits.
In what circumstances would this be needed?
If there are actual *conflicts* applying the patch to current master, then
yes, asking for an updated patch makes sense. But if the patch was simply
generated against different versions of the modified files, but still
applies cleanly to the current versions of those files (possibly at
different line numbers, possibly with some fuzz), then I think no such
resubmission should be needed, and if you have automation to detect that a
patch was committed and mark the patchwork entry as such, that automation
ought to detect such cases as still being the same patch (even if the log
message also changed).
Joseph S. Myers