Re: [boost] Git permissions model

Subject: Re: [boost] Git permissions model
From: Vladimir Prus (ghost_at_[hidden])
Date: 2013-12-08 23:30:56

On 09.12.2013 08:04, Gavin Lambert wrote:
> On 6/12/2013 15:54, Quoth Beman Dawes:
>>> I think the Linux kernel uses git's built in pull request mechanism. I
>>> don't know anything about it, so I don't know if it would be
>>> appropriate for us. Most people do seem to prefer using github, and as
>>> many of our contributors are windows users they might be more
>>> comfortable using a web interface than the command line. Here's Linus
>>> Torvalds writing about it in his charming manner:
>>>
>>> https://github.com/torvalds/linux/pull/17#issuecomment-5654674
>>>
>> He isn't the only one who doesn't like GitHub's (as distinguished from
>> git's) pull request mechanism. I read a blog about that a couple of days
>> ago, where the author talked about how submitting a fix to an open source
>> project was a process over time, not a single even. It has to start to with
>> submitter having some feeling for how the project handles maintenance,
>> testing, docs, etc. and progress through a dialog.
>
> Speaking as one who has made several pull requests on GitHub (though admittedly only to a small number of projects), I can definitely attest
> to them being a process over time.  (But that's what you'd expect, and want, usually.)
>
> Each request has both a discussion thread and a branch, allowing the maintainer to test the code and recommend additional changes be made by
> the submitter (even if just to merge up to latest HEAD and resolve conflicts if it takes a while).
>
> I've had some simple requests get merged almost immediately, and more complex ones take several months until the maintainer can find time to
> look at them properly.  But the process was fairly smooth both ways.

Honestly, I still prefer gerrit model over github fork/pull-request model, where to publish a patch for review you just do, in
your local git clone, something like:

        git push review

And this creates a review request on the server. So, no need to bother with a work, or pull request. And then, if you wish to
revise your patch, just run the same command again. And a reviewer can actually fetch your patch locally, for testing, whereas
github instructions for same are long-winded. Effectively, gerrit creates a somewhat hidden branch you can use to collaborate
on a patch in a rather direct way.

There are some approaches for integrating github and gerrit, but I don't know how well they work.

- Volodya