Re: Is it time to drop ChangeLogs?

[Ted Zlatanov]

On Wed, 06 Jul 2016 10:39:35 -0700 John Wiegley <address@hidden> wrote: 

JW> I may be a strange one here, but I like the ChangeLog format for commit
JW> messages. It's not unreasonable to ask a submitter to take some care and 
pride
JW> in their description of the changes they've made -- after all, they've 
spent a
JW> fair bit of time preparing the change itself.

All right, that's very reasonable.

JW> If writing a ChangeLog entry to describe a change increases the time spent
JW> crafting a patch by 10%, and if this loses a contributor who would have
JW> otherwise sent us code, I'm forced to wonder in what other ways have they've
JW> been hasty, such that working on the commit message was too much for them.

I disagree with this. Processes such as the one here are learned
behavior, not something that identifies good vs. bad programmers.

On Wed, 06 Jul 2016 20:23:32 +0300 Eli Zaretskii <address@hidden> wrote: 

EZ> That's already so.  The number of times I had to reformat log messages
EZ> for casual contributors is too large to remember.  You just suggest to
EZ> codify that, so they won't feel obliged to even try to format the
EZ> messages as we want them.
...
EZ> Sorry, I don't understand how this will work.  Can you explain?  Let's
EZ> say I received a pull request, and the commit's log message needs
EZ> reformatting.  What next?

The code doesn't get merged until the commit is up to our standards. So
even if the ChangeLog format doesn't change, this is still a good way to
prevent bad code or bad commit messages from making it into Emacs. The
fixes are up to the contributor; the reviewer will almost never have to
rewrite things on their own.

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

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

I think we already do this to some degree in emacs-bugs, but without a
process (so casual contributors often don't know where to start).

I agree manpower is a concern. Perhaps a pull request process would
actually take work off our shoulders by simplifying the steps so more
people can be reviewers.

On Wed, 6 Jul 2016 19:41:15 +0200 Paul Eggert <address@hidden> wrote: 

PE> I have the sense that pull requests work better in projects with a large 
number
PE> of occasional committers and a small number of full-time developers who 
triage
PE> and review. Emacs development doesn't work that way: among other things, 
there
PE> are no full-time developers, and we don't have enough reviewer time. So it 
may
PE> not be a good fit for the pull-request model. (It might make sense to change
PE> Emacs's development model but that's a larger topic....)

Good points; Eli noted that as well. I don't have proof one way or the
other, but my feeling is that it would be a change for the better.

Ted