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: Siddhesh Poyarekar <siddhesh at redhat dot com>
- To: Joseph Myers <joseph at codesourcery 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 17:19:52 +0530
- 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> <alpine dot DEB dot 2 dot 10 dot 1508051104360 dot 7214 at digraph dot polyomino dot org dot uk>
On Wed, Aug 05, 2015 at 11:09:55AM +0000, Joseph Myers wrote:
> 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
> after-the-fact fix-up.
OK, understood.
> 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.)
That would be a lot to take on I agree :) Lets use 2.23 to figure out
the workflow and then hopefully it'll be settled by 2.24.
> I don't see the point in a [committed] message if only the log message has
> changed.
Any change in the content of the patch, including the commit log and
even the date and time will result in the commit id being changed.
patchwork identifies patches based on their commit ids, so a changed
commit id means that the patch does not get marked.
> 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).
The patch should apply using git-am. Any other fix up for fuzz or
commit log messages imply a change in the commit id altogether, which
means manual intervention to clean up patchwork.
But maybe I'm try too hard to automate everything in patchwork in the
first go. Most patches (at least once the workflow has settled)
should go in as is without modifications, so in theory, a
significantly less number of patches would need to be cleaned up in
patchwork.
Siddhesh