Re: Is it time to drop ChangeLogs?

[Phillip Lord]

Alan Mackenzie <address@hidden> writes:

> Hello, Phillip.
>
>> > The term seems to imply that instead of a contributor pushing a change
>> > from his machine to a central repository, some specially authorised
>> > authority would pull the change from the contributor's machine.  This
>> > would seem to imply every contributor needing to set up an scp daemon on
>> > his local machine, which doesn't feel like a Good Thing.
>
>> On *some* machine, yes. That can be their own server, or a hosted git
>> repository, or a branch on the Emacs git repository.
>
> The only one of these usable by me would be the last one. I can
> foresee this branch would be open to anybody to commit anything, and
> could quickly fill up with questionable changes. Anybody using this
> method would need to maintain their own copy of this "pull" branch.
> This could lead to quite a few logistical problems, could it not?

It doesn't in my experience. In generally, you create a feature branch
for each thing you want included. Once it is merged to mainline, you
throw it away again. If you are worried about permissions the repo could
be created with individualized namespaces (so phil/* branches would be
readable by all, but writeable only by me).


> Also, the email containing the patch is not the source for what gets
> merged?  This seems inefficient.

There is no patch. Discussion happens on each PR, when everyone is
happy, you rebase trunk against the feature branch, merge back to trunk,
and kill the feature branch.

At the moment, many of the patches that get discussion here do not
contain all the information anyway; I think patches with commit message
are the minority. So in many ways this is better.

Phil