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