On Tue, May 4, 2010 at 4:03 PM, Allison Randal <[email protected]> wrote: > On 5/4/10 1:14 AM, James E Keenan 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. > > Thanks for this Jim. I hope you didn't feel too much like a poster-child. :) > I really do feel substantially more comfortable with git knowing you're > comfortable with it. The same is true for Coke, who was hesitant about git a > year or so ago, but is now in favor.
See below. > I would like to hear from anyone who has reservations about a move to git. Yes, we've all been asking for that for some time. There's a wiki page for this at http://trac.parrot.org/parrot/wiki/GitObjections; The only unanswered issue on that page is git/trac integration, and we're nearly there. (see below) > This is a serious decision, not to be taken lightly. With code changes we > can rollback a bad commit or branch merge. Infrastructure changes are > riskier. We planned for *six months* for the move from perl.org to > parrot.org, even though it was only a change of servers using the same > tools. It was mostly smooth, but we still didn't get it all right (see > Patrick's comments on Rakudo not getting enough notice). > > >> (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. Except, perhaps, for the svn advocates. YMMV. > I've noticed this. I apologize to anyone who feels like I haven't been > listening to them. I'm really trying, but my reaction to this kind of > enthusiasm is generally to discount what the person is saying because it > isn't cool, hard logic. Which is why we've been collecting issues and addressing them on the wiki. >> (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. > > So far, the compelling reason I've been given for why we should move to git > is branch merging. But, it's been demonstrated quite effectively that the > git merging tools work on an svn data-store. Except for the mismatch with svn properties & empty directories and ignores and a few other things. The actual merging of /changes/ is quite nice, yes. > I totally understand that some people prefer working in git, and as far as I > know most of them already are (pulling from the svn central data-store). > What I don't understand is what advantage we gain from using git as the > central data-store. As far as I can tell, in the age of distributed version > control the format of the central data-store is entirely irrelevant. (At if > it really is irrelevant, the weight is on keeping what you already have > because of the cost of migration.) My issues with git have primarily been with git-svn; There are things you can do with git that you cannot do with git-svn. My largest pain point with git has been here. Now I know. My pain with straight git on partcl & rakudo has been very much lower, and even that has been mitigated by the other parrot developers who use git and have been extremely helpful. >> (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? > > The funny thing is, AFAIK no one whats to switch to distributed development > patterns. The git advocates want to use git as a centralized repository. If > we were planning to move to a more distributed development pattern, I would > consider git a greater advantage. Andrew talks about this in a followup post, but yes, we're currently comfortable with a more central style. Using git would allow us the flexibility to change the workflow, but doesn't force it. I can definitely see us moving this way in the future, but the centralized style fits our workflow currently and helps keep the adoption pain for people learning git low... >> (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? > > I consider all three equally good. Well, of the three I actually have a > personal preference for bazaar, but they are technically equivalent. > >> (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.) > > This I would like to see a great deal more on. About the only way I'm likely > to be comfortable with a move to git is if we do an entire mock run on the > migration to a test server, including the svn-dump-and-git-import, the > integration with Trac, email notifications, and our tools for access control > management. We need to figure out hosting, if our current hosting can > support git, if we'd use a service like githib. We need to figure out if > Trac integration will work if git is hosted on a different box (svn and Trac > have to be hosted on the same server for the integration to work). I want to > know if we can do bzr and svn mirrors from git. I've already asked the OSUOSL folks for help here - they seemed eager to help us setup a trac/git demo instance; I've got cotto cc'd on the ticket. (See today's parrotsketch for more on this.) > I also want to see the equivalent of our docs/project/committer_guide.pod > written for git. I want to see agreement among the git users on a project > standard for how we setup our local repos, how we do checkouts, commits, > branches, merges, where we publish our private branches, etc. I know git > allows for dozens of different styles of development, but it makes it > enormously difficult to collaborate with other developers when you have to > work around a dozen different ways of doing things (I've already been bitten > by it, and we're not even using git all that heavily at the moment.) I want > a plan for how we'll refer to revisions, and if there is a good way to save > existing references to our 46286 (and counting) revisions, a policy on how > we'll tag releases, and details on how we'll restrict our git hosting to > prevent the more destructive repository-changing commits that git allows. This is basically a consolidation of information that's already out there; we'll need this for any eventual cutover, I can take this as a TODO. Note that we don't have to care about what's downstream of us. We have to care about the `official` versions, and there are definitely different workflows we could follow to decide what makes things official. This is where the centralized model comes in handy for the way we do releases and manage our copyright on what commits are able to be considered for official releases. We can cover the centralized vs. distributed issue in this document. > Ideally, I'd like to spend some time talking to a sysadmin who has done svn > migrations and maintains git repos. Specifically, one who is willing and > open to talk about the disadvantages of git as well as advantages. (All > software has disadvantages. I worked as a sysadmin for years, and I don't > believe anyone who tells me a particular package has none.) These kind of > infrastructure decisions are trade-offs, working out if the mix of > advantages/disadvantages of one system are a better fit for the particular > project's needs than the advantages/disadvantages of another system. > >> (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. > > Unfortunately, I won't be at YAPC::NA. Whatever parrot devs are there can > certainly get together, but it wouldn't be effective at resolving this > conversation. > > I also get the impression that the git advocates would like an answer soon, > so the end of June may be too long anyway. > > Allison This supposes that there is someone to give "them" an answer. Just to be clear, them is us. I don't expect this decision to come from any individual on the board, or even the board as a collective, but to probably come from a supermajority of the members. This discussion has been framed, for good or ill, as a "convince allison" discussion for some time. I'm pretty sure that that is not a healthy direction for us to go in. -- Will "Coke" Coleda _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
