[ruby-core:25303] Re: [Feature #2033] Move Core Development to Git

On Wed, Sep 2, 2009 at 4:29 PM, Eric Hodel<[e-mail]> wrote:
> On Sep 2, 2009, at 11:19, Run Paint Run Run wrote:
>
>> Feature #2033: Move Core Development to Git
>> http://redmine.ruby-lang.org/issues/show/2033
>>
>> Author: Run Paint Run Run
>> Status: Open, Priority: Normal
>> Assigned to: Yukihiro Matsumoto
>>
>> Following from [ruby-core:21039], I formally propose that core developme=
nt
>> switches to Git. The obvious benefits include:
>>
>> * Opens Ruby development to a wider range of contributors. Ruby- and
>> non-Ruby-based projects alike have shown a dramatic upswing in contribut=
ions
>> after moving to Git.
>
> This is scientifically proven?

That's a good line. I assume you're using it rhetorically. The
proposal deserves good-faith consideration.

An observation or three:

Rails saw a surge in number of contributors, number of patches, and
patch quality after moving to git. Several contributors naturally
emerged as vetters and integrators. This widened the patch-examination
bottleneck by naturally spreading the responsibility among other
trusted contributors. No organization was required; this pleasantly
emerged as a property of the system.

I think number of contributors and patches went up just due to
transparency, accessibility, and responsiveness. It's hard to say, but
GitHub had a significant role here. I think patch quality has
increased largely because rebasing a topic branch against the main
line is extremely easy. Old fixes don't go stale.

Furthermore, we recently had an incredible experience with the first
RailsBridge bug mash:
http://wiki.railsbridge.org/projects/1/wiki/BugMash. Git was by no
means the reason for its success, but it acted as a strong enabler.
New users understood the workflow and tools with little trouble;
within two days we'd see 37 first-time contributors' patches applied
to master and hundreds of others'. We hope to repeat the experiment
before every stable gem release.

I was skeptical about moving from svn to git, but it has paid off big
time and in ways I hadn't anticipated. I've completely come around.

>> * Allows tickets to be handled by de facto topic branch maintainers. A
>> contributor interested in improving documentation, for example, could re=
view
>> the documentation tickets, apply the relevant patches to his 'doc' branc=
h,
>> then propose it be merged periodically. The core team could, and should,
>> still monitor this branch's progress, and intercede where necessary.
>> Ultimately, development would suffer less from the current bottleneck
>> effect, allowing contributers to play a larger role.
>
> This sounds like more work than what happens now. =A0How is more work sup=
posed
> to make ruby development faster?

It's more apparent work, of course, but broadly and naturally
distributed among contributors of varying skill and interest using
tools honed for just this purpose.

>> * Complicated feature proposals would take the form of branches. This
>> solves the current problem of patches rotting in Redmine because `rebase=
`
>> and Git's superior merging capability allow the patch to be kept in step
>> with the trunk. Further, this allows parties interested in the feature t=
o
>> collaborate on the branch; only submitting a pull request when they deem=
 it
>> mature.
>
> Can't this be done now with git-svn?

It can, with caveats. You have to shove everything back through the svn fun=
nel.

>> * Experimentation is encouraged because now anybody can branch, and
>> contribute back that branch, with impunity.
>
> Ditto.

Same.

>> * Working with the trunk becomes more pleasurable due to Git's advanced
>> toolset and significant performance benefits.
>
> I've found git less pleasurable and it's "advanced" toolset cumbersome an=
d
> unfriendly. =A0It's largely been a performance detriment to me.

For decentralized development, cheap, effective branching and merging
is awesome and desperately needed. Git and many other SCMs beat the
pants off Subversion in this respect, and this alone is worth it.

In the interest of productive discussion about the topic at hand --
moving from svn to git -- I think we're all be best off discontinuing
a vim/emacsish discussion of whether git is "your style."

Best,
jeremy