Re: [boost] Is Boost dead? [Re: Anyone is interested in being review manager of ‘Application’?]

Subject: Re: [boost] Is Boost dead? [Re: Anyone is interested in being review manager of ‘Application’?]
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2014-05-16 21:09:59

Hi,

Sohail Somani wrote:
> On 16/05/2014 7:21 PM, Adam Wulkiewicz wrote:
>> Hi,
>>
>> Sohail Somani wrote:
>>>
>>> Moving to git was a smart decision but my personal experience has
>>> shown that the current configuration does not encourage forking in a
>>> way that makes it easy to contribute.
>>>
>>> Would anyone know what the rate of incoming patches from outside
>>> developers has been since the change? That would be an easy way to
>>> tell if it's just me being lazy (probably is).
>>
>> I don't understand all of those negative voices. Especially I don't
>> understand how contributing can be considered difficult or harder than
>> before.
>>
>> I'm a contributor at Boost.Geometry and you can believe me or not but
>> getting involved in the Boost library development was never easier than
>> it is now. In Geometry we already have > 30 pull requests closed. On
>> GitHub you can fork one library with one button click, make a change and
>> create a pull request (with 2 button clicks and writing a message).
>> Reviewing the code is extremely simple, you can discuss about the code
>> or make comments about single lines. And working with GIT is a real
>> pleasure WRT the SVN. But you even don't need to know how to use GIT
>> since the changes can be made directly on GitHub or you can use their
>> app on Windows to handle local repos. We have really great tools at hand
>> so we should use them.
>
> Obviously Git is better to use than SVN for Boost, there is no 
> argument there.
>
> Your 30+ pull requests look like they're mostly from the same guy. 
> That's fine, but not a good enough example of how much easier it has 
> become to contribute.

It's the frequency of contributions that matters. The contribution of a 
simple patch takes 5 minutes, assuming that there is someone who can 
review and merge it.

> Time will tell. It's interesting that you're suggesting a Github-based 
> workflow that wouldn't even require a local repo. That could be worth 
> a shot next time. How would I maintain my own personal fork for my 
> projects until the pull request was accepted?

You have many options. When you create a fork of some library a clone of 
the library's repo is created for your profile. You can further clone it 
to create a local copy and commit changes from you local copy, etc. You 
could also modify it directly on GitHub but probably only if the changes 
didn't require running tests.

Now here comes the interesting part. When you're done with the changes 
you can request a pull. Until it's merged you can commit additional 
changes and all of your commits becomes the part of the same pull 
request. This way people can review your work, you can make fixes and 
repeat until your work is accepted.

If you work on a several things in the same time you can make branches 
in your fork, one per each new feature. When you're done request pulls 
to merge your branches with the original library's develop branch and 
review/fix until they're accepted and merged. In the meantime you can 
create more branches or forks of other libraries or comment on other 
people pull requests.

Regards,
Adam