Howdy, I would like to thank kid51++ for the thoughtful email. I agree with everything he says. YAPC this year will be a place where many Parrot core developers are in the same room at the same time, and that is a better venue for important (but not final) decisions.
That being said, I think if everyone who is interested can give three-ish constructive reasons (on parrot-dev and/or blog post) for why Parrot should convert to VCS $X, that would be useful. I think these reasons should concentrate on why it is good for the Parrot community in general, and not concentrate on personal reasons. I think case studies are very valuable here as well. We should interview developers from other open source projects who have converted VCS's recently, and see what we can learn from them. Not learning from their mistakes is just plain dumb. I think most core developers agree that Subversion is not serving us well. Everyone wants to be more productive and have fewer hoops to jump through to do amazing things with Parrot. Let's try to make the process of migrating something that brings us together instead of dividing us. Duke On Mon, May 3, 2010 at 5:14 PM, James E Keenan <[email protected]> wrote: > 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 > -- Jonathan "Duke" Leto [email protected] http://leto.net _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
