emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Is it time to drop ChangeLogs?


From: Eli Zaretskii
Subject: Re: Is it time to drop ChangeLogs?
Date: Thu, 10 Mar 2016 08:47:45 +0200

> Cc: address@hidden, address@hidden
> From: Paul Eggert <address@hidden>
> Date: Wed, 9 Mar 2016 15:39:25 -0800
> 
> On 03/09/2016 12:21 PM, Eli Zaretskii wrote:
> > it's fortress -- if you dismantle one of its bastions, the others
> > will soon fall as well.
> 
> It's not a fortress, as is demonstrated in other GNU projects. For 
> example, here are the last three commit messages for coreutils, which 
> has been using the proposed approach since 2008. These commit messages 
> are just as good as what we typically see for Emacs. Maybe better. I'm 
> sure we can improve the quality of Emacs commit messages, but putting 
> them into ChangeLog files is not necessary or even all that helpful for 
> doing so.
> 
>    commit e735d417fb2e5c7427b3622f2a78e65e450b49a8
>    Author: Eric Blake <address@hidden>
>    Date:   Tue Mar 8 16:01:34 2016 -0700

If I could by some magic wand make a few distinguished individuals
become part of the Emacs team, and never give write access to anyone
else, then those two would certainly be on the list.  And then we
could simply forget about the problems we are arguing ab out, because
they would have become nonexistent.

But as long as we are trying to make Emacs development be more
crowdware (which I think is a correct direction, given that Emacs is a
very large collection of loosely-related packages), we cannot rely on
the high quality of log messages produced by the individual
contributors, because many of them will only casually contribute, and
won't have the kind of experience and habits that Eric and Jim have.

We must have a convenient way of correcting the log messages.  The
alternative is to give push rights to a very few individuals, and have
a patch review process through which the log messages could be
corrected before pushing, but that requires more manpower than we
currently have, so it cannot be used for now.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]