Toward a Better Discussion of Parrot's Future VCS Options

James E Keenan jkeen at verizon.net
Tue May 4 00:14:19 UTC 2010


Friends,

My name and nick were invoked recently on #parrot as part of the VCS 
wars.  Since $job usually precludes my attendance at #parrotsketch, let 
me state my position here.

1.  I proceed from the following premises:

(a) Since we're no longer adding new code written in Perl 5 to the 
distribution, there's not that much for me to do in the project right 
now except testing and touch-ups of bad code I stumble upon during 
testing.  So I don't have as much invested in the VCS wars as those who 
are contributing to the Parrot core.  I can probably live with any 
decision that is reached.

(b) I have extensive experience with centralized VCSes, principally 
Subversion, less so CVS and Perforce.  That experience with Subversion 
started with the Phalanx project, extended to my own CPAN distributions, 
was extensively augmented at $job, and capped off with Parrot.  At both 
$job and in Parrot project, I have been a strong advocate of doing 
development in branches and of merging branches to trunk only when you 
are ready to install into production.  (Implication:  I believe trunk 
and production should, cet. par., mirror each other.)  At both $job and 
in Parrot, my experience has mainly been in situations where we either 
do not have a release manager or where the release manager's primarily 
is to release a tagged revision and does not entail cherry-picking of 
commits.

(c) I have some experience with one distributed VCS:  git.  My three 
newest CPAN distributions are all stored at github.com, as does my work 
with the David Golden-maintained ExtUtils::ParseXS.  However, in all 
these cases I have been the sole committer so far.  So I haven't had to 
perform any merges, rebases, etc., with git.  For me, git's strongest 
advantage over Subversion so far is that the output of 'diff' and 'log' 
are immediately fed to a pager!  And the best discussion I ever had 
about git's strengths and weaknesses took place just this past Saturday 
night over beer with Randal Schwartz!

(d) VCSes come in and out of fashion and tend to spark passionate -- 
even hyperbolic -- arguments on the part of their adherents.  IIRC, at 
YAPC in 2001, everyone was raving about darcs.  By 2004, Subversion was 
in.  By 2006, the cool kids were using SVK on top of Subversion.  And by 
2008, the same people who were raving about SVK had moved on to git. 
And my impression is that -- perhaps inspired by Linus Torvald's 
notorious talk at Google -- git advocates are more prone than others to 
scoff (or worse) at those who disagree with them.

(e) If there is a dispute over an open source project's policies and 
practices, the burden of proof falls on those in the project who wish to 
change those policies or practices.  The rationale for change and its 
supporting evidence should be presented in a more or less structured way 
on the project's mailing list or in some other appropriate forum. 
Simply sounding off on IRC about how you could be so vastly more 
productive you could be if only the project changed policy X is 
insufficient.   The more you whine about a project's policies on IRC, 
the less I am impressed with your argument.

(f) The more contentious the discussion over a project's policies and 
practices becomes, the more important it becomes to try to resolve the 
issues in a face-to-face context.  At a certain point, online tools no 
longer suffice.

2.  It follows the premises above that to date I am not favorably 
impressed with the quality of the discussion of VCS changes in the 
Parrot project.  Even though I am not as skeptical of git as Allison is, 
I do believe that she is correct to challenge the git advocates to 
provide better substantiated arguments than they have so far.

3.  But rather that stake out a particular position, I would like to 
suggest a way forward.  This has two aspects:  the questions that I 
would like to see addressed; and the venues in which that discussion 
should take place.

(a) Questions needing discussion:

(i) What are the strengths and weaknesses of both centralized and 
distributed VCSes?  Should Parrot move away from a strictly centralized 
VCS?  If so, given that distributed systems can be set up with 
quasi-centralized repositories (this is what's happening at $job), how 
decentralized should our distributed VCS be?

(ii) There are at least three distributed VCSes that, on the basis of 
their adoption by other large, open-source projects, deserve our 
attention:  git, mercurial and bazaar.  What are the strengths and 
weaknesses of each?  Are there people we can speak with who have 
extensive experience with two or more of these?

(iii) If we do decide to move to a distributed VCS and settle on a 
particular VCS, what shall our migration plan be?  (Note:  On the basis 
of my past and current experiences, this is the issue that needs the 
most discussion but will likely get the least.)

(b) Venues for discussion:

(i) As suggested above, I don't think IRC is a satisfactory venue for 
this discussion.  In fact, I'm going to state right now that between now 
and YAPC I'm not going to pay attention to anything whatsoever said on 
#parrot concerning Parrot's VCS choices.  (I may go so far as to take a 
leaf from Andy Dougherty and avoid IRC altogether.)

(ii) I recommend that people who want to address 3(a)(i) or 3(a)(ii) do 
so either via posts to the parrot-dev mailing list (like this post), or 
by posts there which link to a blog which can be aggregated on 
planet.parrotcode.org.

(iii) For reasons I don't understand, the Parrot leadership apparently 
decided not to schedule a Parrot workshop at the time of YAPC::NA::2011 
in Columbus next month.  But then it appears that Patrick Michaud 
contacted the conference organizers and got one side room set aside for 
Parrot and Perl 6 for all three days of the conference!  (This is 
space/time distinct from conference presentations by Patrick, Jonathan 
Leto and others.)  So we have the time and space and, together with 
Rakudo and other Perl 6 folks, we need to figure out how to fill it.  I 
propose that we set aside some time in that room for a structured 
discussion of our VCS options.  Now, since only some of our committers 
can or will be present in Columbus, we can't authorize the participants 
in such a discussion to make final decisions for the whole project.  But 
a face-to-face discussion of these issues will be invaluable, 
particularly if we have position papers posted in advance of YAPC.

Thank you very much.
kid51




More information about the parrot-dev mailing list