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: Wed, 06 Jul 2016 20:23:32 +0300

> From: Ted Zlatanov <address@hidden>
> Date: Wed, 06 Jul 2016 13:03:07 -0400
> 
> On Wed, 06 Jul 2016 19:36:30 +0300 Eli Zaretskii <address@hidden> wrote: 
> 
> EZ> What format do you suggest instead?
> 
> "Summary line.
> 
> Details..."
> 
> Where the Details can be in the current or another format or whatever
> works for the contributor. The per-file summary would be available from
> the pull request system, regardless of the formatting of the commit message.

That's already so.  The number of times I had to reformat log messages
for casual contributors is too large to remember.  You just suggest to
codify that, so they won't feel obliged to even try to format the
messages as we want them.

> EZ> The advantage of the current formatting is that we have Emacs features
> EZ> which support it very well.  Any other formatting will have to grow a
> EZ> similar support first.  And then we all need to re-learn.
> 
> Good points. I'm trying to say all the support code can move to the pull
> request system, so it won't go away, and the transition can be gradual.

Sorry, I don't understand how this will work.  Can you explain?  Let's
say I received a pull request, and the commit's log message needs
reformatting.  What next?

> EZ> IOW, isn't this suggestion going to favor casual contributors over
> EZ> those who push commits day in and day out?
> 
> Yes, exceptions should be made for those regular contributors. But you
> know that some features merit discussion, even if a very senior
> contributor wants them.

Our current practice is to discuss when the commit is already pushed.

> If I understand correctly, your concern is about logistics rather than
> about the fundamental benefits of such a system. I share your concerns
> and think the risk is worth the benefit.

My concern is about the manpower.  If we don't have enough, this is
going to be an exercise in futility.

So I'd suggest first to have enough patch reviewers step forward and
volunteer, before we start thinking about such a process seriously.



reply via email to

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