[Top][All Lists]

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

Re: Is it time to drop ChangeLogs?

From: Ted Zlatanov
Subject: Re: Is it time to drop ChangeLogs?
Date: Thu, 07 Jul 2016 09:18:51 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

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
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 


reply via email to

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