Notes for DLang maintainers

[Andrei Alexandrescu via Digitalmars-d]

On 02/28/2017 10:04 AM, Vladimir Panteleev wrote:
> On Tuesday, 28 February 2017 at 14:52:36 UTC, Andrei Alexandrescu wrote:
>> Thanks. I'd replace "changes should be split into as many commits as
>> is reasonable" with "changes should be split into as many pull
>> requests as is reasonable", which is a natural consequence of "most
>> pull requests should consist of one commit upon merging". (Of course
>> there may be several commits during PR review.)
>
> Well... not always. For example, introducing a private function that is
> not called from anywhere is something that doesn't really make sense as
> a pull request of its own, but does make sense as a separate commit.
>
>> One vs. several commits per merged pull request is a matter in which
>> reasonable people may disagree, and we can't do both ways. The
>> Foundation fosters that github pull requests are squashed upon
>> merging, with exceptions that need to be justified.
>
> Sorry, but I don't think that's reasonable at all.
>
> I have seen no arguments to support this way of doing things, only
> downsides. Established major projects seem to agree.
>
> As far as I can see, this is not about a subjective point regarding
> which reasonable people may disagree. It seems to be a poorly justified
> mandate, that's all.
>
> As I've mentioned previously, you will need to provide some arguments
> which would outweigh those supporting the opposite position.

There can be any amount of discussion about this, to no conclusive 
results, and any argument may be responded with "I don't buy that". 
That's simply because, again, there's some subjective factor and there 
is no perfect approach that proves the others wrong. To wit, I have 
stated my argument several times in public and private but somehow it 
did not count.

Here we are simply applying a way of doing things that has worked at 
Facebook over six years and two orders of magnitude increase in team 
size. (They use phabricator there, which has a similar workflow.) It is 
obvious to me that other organizations use similar approaches; and also 
that other organizations use different approaches, also with good 
results. I should add that Facebook is one of the most successful 
software companies in history, and that may count for something.

Also, obviously the Internet can be used to find support for anything, 
and with that caveat allow me:

* "Why does every serious Github repo I do pull requests for want me to 
squash my commits into a single commit?" 
http://softwareengineering.stackexchange.com/questions/263164/why-squash-git-commits-for-pull-requests

* "I’ve been contributing to more projects in which it is expected that 
I should submit a pull request that contains a single commit." 
http://ndlib.github.io/practices/one-commit-per-pull-request/

* "Squashing your branch's changes into one commit is "good form" and 
helps the person merging your request to see everything that is going 
on." https://github.com/projecthydra/hydra-head/blob/master/CONTRIBUTING.md

* "But one thing occasionally bothers me, and that's pull requests that 
come loaded with several temporary commits. I often find myself asking 
contributors to squash those into a single descriptive commit." 
http://eli.thegreenplace.net/2014/02/19/squashing-github-pull-requests-into-a-single-commit

I'll stop here. Sure enough, there'd be other links to pages describing 
how many commits per PR work fine. Our organization happens do things 
this particular way, and it's not the only one. Moreover, we are are not 
rigidly enforcing it; within reason, definitely leeway exists.

Vladimir, I am gathering that this makes you unhappy and are close to 
getting ultimative about this. I have made all attempts I could to 
publicly and privately explain matters. I kindly ask you to consider the 
following:

* Any organization, be it for profit (company) or not (university, oss 
project) has certain rules in place. In all likelihood not all 
participants would choose the exact same rules if they could, yet they 
choose to walk (factually or virtually) in there every day and 
contribute to the organization. A simple way to look at things would be, 
would you quit a job or start a protracted argument with the CEO if the 
coding guidelines contained "please squash your github commits"?

* The leader of an organization (in this case me) cannot afford the time 
to justify and debate every single minor decision they make. No 
organization works that way. I am under enormous pressure to bring money 
in the Foundation, organize DConf, mentor students, write articles, 
contribute code, all while keeping things running.

* You seem to frame things as an arbitrary imposition made by an 
oppressive leadership. Think of it - ever since we have worked together 
(your first post is dated 2007-01-06!), is this the pattern by which 
matters have been conducted? Do you think it would be a fair 
characterization of Walter and my philosophy and values?

The short of it is we simply cannot work this way, as a simple matter of 
my own human limitations; I can't spend hours in the forum justifying 
every little thing, especially those that ten people do in eleven ways. 
I mean I _literally_ can't: I don't have the time because I am spending 
it making the D language more successful. Which I hope you'll help me 
with, too. To scale, we need to focus on the real problems and abandon 
debating the small things again and again.



Thanks,

Andrei