On Sun, Sep 12, 2010 at 3:51 PM, Jeff Hammerbacher <ham...@cloudera.com> 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 --------------------------------------------------------------------- To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
