This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Hash out a solution for ChangeLog/NEWS at the Cauldron?

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]