Re: "Forking is a Feature" reactions?

On Sun, Sep 12, 2010 at 3:51 PM, Jeff Hammerbacher <hammer-psgPW5cihnJWk0Htik3J/[email protected]> wrote:
> Hey,

>
> I just read the thoughtful piece by Anil Dash at
> http://dashes.com/anil/2010/09/forking-is-a-feature.html. I don't really
> agree or disagree with his points, but it's an interesting take on the value
> of distributed version control and the evolution of how open source
> communities get work done.
>
> I tried to find the official position of the ASF on this topic, but
> unfortunately, the "How it Works" links are broken on the site (see
> http://issues.apache.org/jira/browse/INFRA-2981).
>
> I did find, in the "glossary", a section on "Revolution":
>>
>> In the Apache environment, some communities may decide to permit (or
>> encourage) revolutions as ways of reconciling differences, particularly code
>> changes which have been blocked on a particular branch by a veto. Originally
>> described by James Duncan Davison in his 'Rules for Revolutionaries,' the
>> concept has been adopted, formally or informally, by at least one Apache
>> project. Essentially, a revolution occurs when a group of committers decides
>> to fork the current main branch in order to work on problematic code or
>> concepts. This permits them to pursue it without disturbing the evolutionary
>> work on the main branch. A revolutionary branch may eventually be merged
>> back into the main branch, die out, split completely and become a new main
>> branch, or may absorb the current main branch into itself (essentially no
>> different than the first option). See the 'Rules for Revolutionaries' and
>> compare evolution.
>
> In the Apache Hadoop project, we've adopted the potential for revolutions,
> which we manage as Subversion branches. Unfortunately, maintaining a
> Subversion branch is expensive, and merging it back into trunk can be quite
> difficult.
>
> For projects which have sanctioned "revolutions", it may be useful to allow
> them to use git or another dvcs as the primary version control system.
>
> Similarly, for projects with several large commercial backers, each
> maintaining their own patch sets or source repositories (e.g. Apache Hadoop,
> with Yahoo, Cloudera, and soon, Facebook working separately), a distributed
> version control system could be useful.

I don't view those large external patch sets as a positive thing for
health of an Apache project, or for the average consumer/user of the
project.  I don't view this as a good reason to promote git.

As Sam mentions in his blog post he linked in the thread[1], I also
use git every day for most non-ASF projects.  I don't find git itself
innovative for my use cases, I find github innovative.  I am far more
interested in figuring out better ways of combining issue tracking,
code review, and pull requests, than any desire to ease the pain of a
large external patch.  Large external patchsets are bad.  They
shouldn't be the reason we move to another VC.

I think we should look more critically at the flows that github is
promoting, and look at how we could apply those; regardless of weither
it used svn, git, hg or even bazzar.

[1] - http://intertwingly.net/blog/2010/09/13/One-True-Way