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
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
