www-community mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Hammerbacher <ham...@cloudera.com>
Subject "Forking is a Feature" reactions?
Date Sun, 12 Sep 2010 22:51:36 GMT

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

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<http://www.apache.org/foundation/glossary.html#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<http://incubator.apache.org/learn/rules-for-revolutionaries.html>'
> and compare *evolution*<http://www.apache.org/foundation/glossary.html#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

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'd love to hear the reactions of other ASF members to the piece. I'd also
love to be directed to previous discussions on the topic, as I know that
adopting git for some projects has been discussed previously.


View raw message