Re: How far should we trust ChangeLog attribution dates?

[Thomas Schwinge]

Hi!

On Thu, 21 Dec 2017 17:55:28 -0500, "Eric S. Raymond"  wrote:
> Jason Merrill :
> > YMD in the ChangeLog is typically commit date rather than authorship
> > date anyway, so (i) and (iii) shouldn't differ much at all, and (i)
> > seems simpler.
> 
> I have not generally observed this to be true. Maybe it's a GCC-local thing?

No, that's general GNU policy, see
:
"When you install someone else’s changes [...] for the date, that should
be the date you applied the change."

> When I was an active Emacs contributor but did not have commit access
> yet, it was strongly expected that if you shipped a patch to be merged
> it would include a ChangeLog entry.  The attribution line would be
> therefore have to be the date you made your patch - you couldn't know
> the commit date in advance.

..., and the the person doing the commit is expected to change that to
the current date.  (Don't ask me why...)


Grüße
 Thomas

Re: How far should we trust ChangeLog attribution dates?

[Janne Blomqvist]

On Fri, Dec 22, 2017 at 12:22 PM, Thomas Schwinge
 wrote:
> Hi!
>
> On Thu, 21 Dec 2017 17:55:28 -0500, "Eric S. Raymond"  
> wrote:
>> Jason Merrill :
>> > YMD in the ChangeLog is typically commit date rather than authorship
>> > date anyway, so (i) and (iii) shouldn't differ much at all, and (i)
>> > seems simpler.
>>
>> I have not generally observed this to be true. Maybe it's a GCC-local thing?
>
> No, that's general GNU policy, see
> :
> "When you install someone else’s changes [...] for the date, that should
> be the date you applied the change."
>
>> When I was an active Emacs contributor but did not have commit access
>> yet, it was strongly expected that if you shipped a patch to be merged
>> it would include a ChangeLog entry.  The attribution line would be
>> therefore have to be the date you made your patch - you couldn't know
>> the commit date in advance.
>
> ..., and the the person doing the commit is expected to change that to
> the current date.  (Don't ask me why...)

My secret desire is that once we get this done we would drop these
silly ChangeLogs. Although I'm not a kernel developer, I kind of like
the Linux kernel style, where the commit msg contains a reasonably
in-depth motivation for the change, sort of like the email message one
sends to gcc-patches when introducing a patch (in fact, if one uses
git format-patch + git send-email this kind of workflow is supported
out-of-the-box).  I find that a lot more useful than a screenful of
"Likewise". YMMV.


-- 
Janne Blomqvist

Dropping ChangeLogs

[Eric S. Raymond]

Janne Blomqvist :
> My secret desire is that once we get this done we would drop these
> silly ChangeLogs. Although I'm not a kernel developer, I kind of like
> the Linux kernel style, where the commit msg contains a reasonably
> in-depth motivation for the change, sort of like the email message one
> sends to gcc-patches when introducing a patch (in fact, if one uses
> git format-patch + git send-email this kind of workflow is supported
> out-of-the-box).  I find that a lot more useful than a screenful of
> "Likewise". YMMV.

I strongly endorse this position.

Janne is correct to point out that git is designed to be used in a
patch-centric workflow with a specific style of commenting - summary
line, plus optional separator and running text.  This is expressed
especially in the UI design of git log and gitk.

ChangeLogs are a relic from the days before version-control systems with
real changesets. When you have real changesets, all ChangeLogs do is
add unnecessary process friction.

You guys will and should make your own project policy, but from
watching lots of transitions I will tell you that I think the sooner
you switch over to the Git style of commenting the better for everybody.
-- 
http://www.catb.org/~esr/";>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.

Re: Dropping ChangeLogs

[Eric Botcazou]

> ChangeLogs are a relic from the days before version-control systems with
> real changesets. When you have real changesets, all ChangeLogs do is
> add unnecessary process friction.

ChangeLogs make it possible to quickly pinpoint unintentional changes going in 
the commits.  Maybe git has specific counter-measures against them, but that's 
useful at least with Subversion.

-- 
Eric Botcazou

Re: Dropping ChangeLogs

[Florian Weimer]

On 12/22/2017 12:42 PM, Eric Botcazou wrote:

ChangeLogs are a relic from the days before version-control systems with
real changesets. When you have real changesets, all ChangeLogs do is
add unnecessary process friction.


ChangeLogs make it possible to quickly pinpoint unintentional changes going in
the commits.  Maybe git has specific counter-measures against them, but that's
useful at least with Subversion.


It's less of a problem with Git because of its support for local 
branching, so it's less likely that you reuse the same tree for 
different work.


*However*, my main problem with getting rid of ChangeLogs is that 
without a pull-request-based contribution procedure or some tool support 
like Gerrit, it's impossible to tell which parts of a patch submission 
make it into a commit message.  For glibc, we regularly have commits 
where the commit message is not informative at all, and we don't really 
know what will be committed by a contributor before the fact.


Thanks,
Florian

Re: Dropping ChangeLogs

[Siddhesh Poyarekar]

On Friday 22 December 2017 05:41 PM, Florian Weimer wrote:
> *However*, my main problem with getting rid of ChangeLogs is that
> without a pull-request-based contribution procedure or some tool support
> like Gerrit, it's impossible to tell which parts of a patch submission> make 
> it into a commit message.  For glibc, we regularly have commits
> where the commit message is not informative at all, and we don't really
> know what will be committed by a contributor before the fact.

IIUC the way the kernel community solves this is by ensuring that the
patch in the mailing list makes it in exactly as is so that the mbox for
the email can simply be git-am'd into the repo.  That is, subject line
and mail body become commit messages.  This could actually make tools
like patchwork effective too since patches on patchwork can then be
reliably auto-closed in the post-commit hook.

Siddhesh

Re: How far should we trust ChangeLog attribution dates?

[Richard Kenner]

> My secret desire is that once we get this done we would drop these
> silly ChangeLogs. Although I'm not a kernel developer, I kind of like
> the Linux kernel style, where the commit msg contains a reasonably
> in-depth motivation for the change, sort of like the email message one
> sends to gcc-patches when introducing a patch (in fact, if one uses
> git format-patch + git send-email this kind of workflow is supported
> out-of-the-box).  I find that a lot more useful than a screenful of
> "Likewise". YMMV.

The point of the "likewise" is to show which functions changed.  I
think that's at least as important as the detailed motivation for the change.

Re: Dropping ChangeLogs

[Florian Weimer]

On 12/22/2017 01:20 PM, Siddhesh Poyarekar wrote:

On Friday 22 December 2017 05:41 PM, Florian Weimer wrote:

*However*, my main problem with getting rid of ChangeLogs is that
without a pull-request-based contribution procedure or some tool support
like Gerrit, it's impossible to tell which parts of a patch submission> make it 
into a commit message.  For glibc, we regularly have commits
where the commit message is not informative at all, and we don't really
know what will be committed by a contributor before the fact.


IIUC the way the kernel community solves this is by ensuring that the
patch in the mailing list makes it in exactly as is so that the mbox for
the email can simply be git-am'd into the repo.  That is, subject line
and mail body become commit messages.  This could actually make tools
like patchwork effective too since patches on patchwork can then be
reliably auto-closed in the post-commit hook.


The Linux community does not have a tool-based solution for that.  I 
think it mainly relies on lack of commit access for contributors.


Thanks,
Florian

Re: Dropping ChangeLogs

[Siddhesh Poyarekar]

On Friday 22 December 2017 05:57 PM, Florian Weimer wrote:
> The Linux community does not have a tool-based solution for that.  I
> think it mainly relies on lack of commit access for contributors.

Sure, but that's a minor detail to implement once we decide we don't
need ChangeLogs.  As far as glibc is concerned, I don't think we have
reached that conclusion yet.

Siddhesh

Re: Dropping ChangeLogs

[Florian Weimer]

On 12/22/2017 01:34 PM, Siddhesh Poyarekar wrote:

On Friday 22 December 2017 05:57 PM, Florian Weimer wrote:

The Linux community does not have a tool-based solution for that.  I
think it mainly relies on lack of commit access for contributors.


Sure, but that's a minor detail to implement once we decide we don't
need ChangeLogs.  As far as glibc is concerned, I don't think we have
reached that conclusion yet.


I cannot agree with that.  Full commit review is an absolute requirement 
before we can eliminate ChangeLogs because the review needs to cover the 
author attribution.


Thanks,
Florian

Re: Dropping ChangeLogs

[Siddhesh Poyarekar]

On Friday 22 December 2017 06:06 PM, Florian Weimer wrote:
> I cannot agree with that.  Full commit review is an absolute requirement
> before we can eliminate ChangeLogs because the review needs to cover the
> author attribution.

We have agreed on doing full commit reviews multiple times (at least the
last couple of Cauldrons, including this year's) but implementation has
been inconsistent.

So we have agreement in principle on everything needed get a proper git
workflow (with or without a tool) except dropping ChangeLogs, which is
why I mentioned that as the main blocker.

Siddhesh

Re: Dropping ChangeLogs

[Joseph Myers]

On Fri, 22 Dec 2017, Eric S. Raymond wrote:

> Janne Blomqvist :
> > My secret desire is that once we get this done we would drop these
> > silly ChangeLogs. Although I'm not a kernel developer, I kind of like
> > the Linux kernel style, where the commit msg contains a reasonably
> > in-depth motivation for the change, sort of like the email message one
> > sends to gcc-patches when introducing a patch (in fact, if one uses
> > git format-patch + git send-email this kind of workflow is supported
> > out-of-the-box).  I find that a lot more useful than a screenful of
> > "Likewise". YMMV.
> 
> I strongly endorse this position.
> 
> Janne is correct to point out that git is designed to be used in a
> patch-centric workflow with a specific style of commenting - summary
> line, plus optional separator and running text.  This is expressed
> especially in the UI design of git log and gitk.
> 
> ChangeLogs are a relic from the days before version-control systems with
> real changesets. When you have real changesets, all ChangeLogs do is
> add unnecessary process friction.

I proposed removing the GNU Coding Standards requirement for ChangeLog 
format when using a public distributed VCS with per-logical-changeset 
commits in 
 
(discussion continues in August, September, November).  However, each time 
the discussion has tailed off without reaching a conclusion from RMS to 
remove the requirement, or a conclusion that it should not be removed.

(The use of ChangeLog *files*, as opposed to the *format*, is a peripheral 
matter - the GNU Coding Standards already allow generating such files for 
release tarballs from appropriately-formatted commit messages rather than 
needing to check in ChangeLog files, but it's the format that forces a 
focus on a particular level of detail that duplicates the information 
available from the patches themselves in the VCS.  Thus, whether something 
generated from commit logs is required to be in release tarballs when not 
using ChangeLog format is also a peripheral matter.  GCC already has a 
complicated script for release (and snapshot) tarball generation, which 
we'll need to update for moving to git.  glibc just uses "git archive", 
but if some form of log were required in release tarballs it would always 
be possible to have a step in the (long) release checklist of generating 
and checking in such a file right before tagging the release, and so still 
to use "git archive".)

I have used git-style commit messages (with the ChangeLog content at the 
end) in GCC for some time.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Dropping ChangeLogs

[Eric S. Raymond]

Joseph Myers :
> I proposed removing the GNU Coding Standards requirement for ChangeLog 
> format when using a public distributed VCS with per-logical-changeset 
> commits in 
>  
> (discussion continues in August, September, November).  However, each time 
> the discussion has tailed off without reaching a conclusion from RMS to 
> remove the requirement, or a conclusion that it should not be removed.

Hm.  Maybe it's time for somebody to force the issue, then.
-- 
http://www.catb.org/~esr/";>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.