Re: [boost] [git] Why are we using Github (was: The any library does not pull cleanly because of a forced update on develop and master)

Subject: Re: [boost] [git] Why are we using Github (was: The any library does not pull cleanly because of a forced update on develop and master)
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2013-12-18 18:10:51

On 12/18/2013 07:08 PM, Peter A. Bigot wrote:
> On 12/18/2013 11:22 AM, Bjørn Roald wrote:
>> On 12/18/2013 01:32 PM, Vladimir Prus wrote:
>>> On 18.12.2013 16:11, Mateusz Loskot wrote:
>>>> I know Boost allows use of PRs [1], but not sure if it allows use of
>>>> corresponding
>>>> features at GitHub for code reviews, etc.
>>>>
>>>> [1]https://svn.boost.org/trac/boost/wiki/StartModPatchAndPullReq
>>>
>>> Regretfully what Linus said about GitHub pull requests, here:
>>>
>>>      https://github.com/torvalds/linux/pull/17#issuecomment-5654674
>>>
>>> rings very true to me.
>>
>> +1
>>
>> the whole GitHub "public" Fork to do Pull Request deal seams a bit heavy
>> handed to me.   I have no real experience in using it though.  In
>> addition if half of what Linus is concerned about has bearing on Boost,
>> then there are reasons to consider alternatives to GitHub Pull Requests
>> IMHO.
>
>
> As I read that thread, much of what he objected to was github's web
> commit interface making it difficult/impossible for contributions to
> conform to the kernel patch standards,

Are you saying none of the problems with the web commit interface apply 
to Boost?  In that case there is no worry.  And boost authors does not 
have to encourage or allow use of the web interface anyway.

> and that github pull requests did
> not meet his work flow requirements.

Are you saying none of the problems with the web commit interface apply 
to Boost?  In that case there is no worry.

> The first part is eliminated if the developer pushes to a github fork
> using standard git commands; then the pull request is simply a
> notification of a proposed submission, which must still conform to the
> upstream project's expectations. The second is only relevant if Boost
> maintainers adopt Torvald's email-oriented workflow.

Well. I read that he is concerned about: real explanation, proper email 
addresses, proper shortlog, and proper diffstat.

Why is those relevant only to Torvald's email-oriented workflow?

He also says: " github identities are random, I expect the pull request 
to be a signed tag, so that I can verify the identity of the person in 
question."

Why is that relevant only to Torvald's email-oriented workflow?  If we 
depend 100% on GitHub login for identification and authentication, would 
not that be a tie-up that make it harder to use alternative tools even 
though they may be superior for certain tasks or as GitHub replacement 
or redundant hosting?

> My experience with using github forks to interact with upstream
> projects/downstream contributors has been that it is convenient to both
> submitter and reviewer, since a cursory inspection can be done on the
> web without integrating a mailer with one's development environment or
> having to pull the changes into a local workspace. The ability to
> provide comments in context with specific commits is also valuable.

Good points that could make GitHub features stand up against 
alternatives that are less convenient with these regards.

> Is there a proposal for an alternative Boost pull-request protocol
> (specifically notification of submission, access to submission, and
> medium for providing feedback on submission) that we could weigh
> against github pull requests?

In this thread and elsewhere people have asked if gerrit 
http://code.google.com/p/gerrit/ have been or, should be considered.  I
am not sure that count as a proposal.  Also it is a question if Boost 
policies should enforce or at least encourage all libraries to use the 
same tools, I think it make a lot of sense to do so.

> I'd prefer not to have to submit zip
> files,

+1

or hunt through mail archives to find discussion related to an
> patch that was written nine months ago and accepted six months ago.

+1

-- 
Bjørn