Re: Is it time to drop ChangeLogs?

[Ted Zlatanov]

On Thu, 7 Jul 2016 09:31:55 +0200 Paul Eggert <address@hidden> wrote: 

PE> On 07/07/2016 04:44 AM, John Wiegley wrote:
>>> I disagree with this. Processes such as the one here are learned behavior,
>>> >not something that identifies good vs. bad programmers.
>> You are right, of course, Ted

PE> Yes and no. Good software engineers are adept at software processes, and 
this is
PE> mainly what distinguishes them from mere good programmers. If we want
PE> high-quality software then we need software engineering, not mere
PE> programming.

You're right, Paul. My point, however, is that writing ChangeLog-style
commits is definitely not something you'll learn in school or in
industry, and we shouldn't turn it into a shibboleth by itself.

Working with GNU software is fun, but it's a tiny community compared to
the world-wide developer community. It's hard to grow it if contributors
are judged on the ChangeLog-style formatting on their first contributions.

On Thu, 07 Jul 2016 12:29:23 +0100 address@hidden (Phillip Lord) wrote: 

PL> Where PRs work better over direct commits is when ever someone wants
PL> comments and feedback. There are two main reasons for this. One is where
PL> commits need to be checked by someone else before going in; the emacs-25
PL> branch is in this state at the moment.

PL> The other is where someone wants feedback on their work, because they
PL> are new, or because they are fiddling with parts of Emacs which they
PL> understand poorly.

Exactly! What I'm suggesting would benefit those two cases the most.

PL> Installing something like gerrit or kallithea would be nice (I have no
PL> direct experience of using either, but they are similar to other
PL> systems). However, this would be considerable work.

PL> Perhaps, as a half way house, we could use the resources that we have.
PL> PRs could go to the bug reporting system. This will, at least, keep all
PL> the conversations in one place. If we can tag these with "has patch"
PL> here as well, it will give an queue also. We would still need to do
PL> something about the Emacs git, in terms of squashability; in practice,
PL> this would probably require something like gitolite as allowing non-FF
PL> pushes on all branches would be a bad thing.

PL> This would not give a nice web interface, nor inline comments, but it's
PL> a start.

So maybe the workflow can be:

1) propose a patch on emacs-bug with tag `has patch'. A Git branch
pointer is also acceptable?

2) a reviewer comments; patch/branch is reworked

3) reviewer signs off and commits patch / merges branch

This is similar to how the Git project does it. It can be a bit chaotic,
but seems to work for their scale (which is similar to Emacs' scale). It
won't require new software.

As Noah mentioned, we already have (1) with
http://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs;include=tags%3Apatch;bug-rev=on
but (2) and (3) are not "expected" or in any way documented. So the
contributor docs would be adjusted to mention these steps. That's a
pretty small amount of voluntary effort, and no one has to follow these
steps that doesn't want to. I sincerely hate the current bug tracker,
but am willing to work with it if that's what it takes to get this
moving. As a first attempt, I'll post my gnus-cloud work when it's ready
for review.

On Thu, 7 Jul 2016 08:43:30 -0400 Noam Postavsky <address@hidden> wrote: 

NP> So maybe we just need some more support in vc-git to make sending
NP> patches less clunky? I've been sending patches to bug threads, and
NP> often getting useful feedback on them (and since it's by email, the
NP> comments can easily be inline). Personally, I don't find it more
NP> clunky than pushing to a branch, and then opening a PR in a web
NP> browser.

For a single patch, e-mail works. For multiple commits, rebasing,
adjusting, it can be overwhelming.

NP> Yes, some patches are forgotten, but I don't see how a PR
NP> "system" makes that less likely to happen, e.g., cask has a bunch of
NP> open PRs sitting around: https://github.com/cask/cask/pulls.

A PR system makes it easier to find forgotten submissions. Usually it
can assign a reviewer, who then should get regular reminders. But, of
course, it won't fix lack of manpower or lack of interest. It's just a
virtual clerk.

On Thu, 7 Jul 2016 12:46:07 +0000 Alan Mackenzie <address@hidden> wrote: 

AM> I don't know exactly what is meant by "pull request" and "pull request
AM> system".  I don't think they are established terms.

AM> The term seems to imply that instead of a contributor pushing a change
AM> from his machine to a central repository, some specially authorised
AM> authority would pull the change from the contributor's machine.  This
AM> would seem to imply every contributor needing to set up an scp daemon on
AM> his local machine, which doesn't feel like a Good Thing.

They are well known today, and have existed (in the form of patch
reviews) for a long time. Wikipedia doesn't have much, but
https://help.github.com/articles/using-pull-requests/ has a pretty good
overview. It shows the Github UI, but the steps are the same without it.

The Git book has some good workflow suggestions as well 
https://git-scm.com/book/ch5-2.html

Ted