on Mar 2nd, 2009Git BoF @ EclipseCon
EclipseCon is coming up, and to my big suprise the Git BoF got accepted.
Initially, this BoF proposal was just a way to get the ball rolling on distributed version control systems at eclipse. In the recent weeks I have learned that the ball has been rolling for some time already and has gained quite a momentum, especially among the committers – just take a look at the comments on Bug 257706.
I’d like to get all stakeholders involved in the discussion. Denis Roy will be there to represent the technical and infrastructure side of things. Apart from downstream consumers, committers, contributors and potential contributors, it would also be really great to have some members of the legal team and the board present to get as many viewpoints as possible.
I know that git support was put on hold at the board meeting in December. The cited reason was the resource cost to deploy and support yet another VCS. While I can understand that concern, especially after the recent investment in subversion, I think there is another issue to consider: The opportunity cost of not deploying a DVCS in the near future. Contributions from developers are the life blood of any open source project, and as such, it should be as easy as possible to get people involved in the development process. I experienced first hand how cumbersome it can be to work with the current infrastructure. Centralized versioning may be fine for corporate software development, but for a project like Eclipse I fear it results in too many hurdles for developers. That’s why I’m hoping we can really get this off the ground sooner rather than later.
Regarding infrastructure costs, it has been my understanding that the effort to setup a repository is relatively low. Which I guess makes sense since each developer has to have his own repository. A possibility might even be to use a third party provider like github, at least during the transition period.
Another interesting issue is what work flow model to adopt if we decided to support a DVCS. Options include a “lieutenant” style process as practiced by the Linux kernel, or a more traditional approach with a central master repository that committers commit to.
These are some of the issues I’d like to discuss in this BoF. I am absolutely stoked to see this happening and am really looking forward to making some progress on this front. See you all there!
I have to say that you are wrong. Lines of code provided by commiters external from eclipse are a tiny percentage of the all. It’s the “open-source-dream” you are living in…
I will not be able to assist to the BoF, so I’ll share my 2 cents…
The “opportunity cost of not deploying a DVCS” is not so large because the Eclipse Development process do not allow contributions of more than 500 lines without IP review (and even smaller ones need to come to Eclipse attached to a bug).
So I think the first thing to discuss is: can the Eclipse Process be evolved to allow the benefits of DVCS? If that’s not possible, only the companies building on top of Eclipse might get the benefit (i.e. they can periodically pull changes from the Eclipse tree into their product’s tree).
It would be interesting to have someone from the legal team into that BoF (and someone to publish a summary after it
)
I understand the hesitation of the Eclipse Foundation w.r.t. the IP issues; however, I feel that moving to a DVCS
is inevitable. One of the primary benefits of DVCS – and git in particular – is in offline usage. The Eclipse webmasters
just went through a round of IT problems. And despite their best efforts, they will again but with the continued success of Eclipse, they face a larger and larger crowd of ‘angry developers’ – the centralized resources (CVS/SVN
repositories, build machines, wiki, etc.) will continue to be stressed and stressed … until the system breaks.
It isn’t just resources at the Eclipse Foundation – here at Oracle, we have to tunnel thru our firewall to get to the
Eclipse SVN machine; about once a month someone in our IT group ‘forgets’ about our approved exception to the tunnel-out rules and closes the port – offline mode would make a dramatic difference in how we operate.
Manuel,
I am really pleased to see the GIT BOF scheduled. Doug Gaff and I have been working to get some discussion around version control into the program materials and have both a panel and a BOF that we were going to try and run on VCS. I like GIT a lot, and it seems to be the front runner in the DVCS realm, but mercurial and bazaar also seem to be compelling.
In an effort to keep all the parties in the game (at least for now) I would love to see a more general BOF that looks at VCS in general. So my question is, do you think we should:
a) change yours to be about VCS in general and cancel the other BOF
b) have the more general VCS BOF and then have your GIT BOF as a second round of discussion
c) something else.
If you could let me know at scottr (at) innoventsolutions (dot) com I will strive to make it happen.
sr
@Reader:
Thank you for illustrating my point so vividly: In my opinion, the difficulties in getting your contributions into eclipse are a major turnoff for potential contributors, and thus a reasonable explanation for the low number of “external” contributions. Another thing to consider is that becoming an external contributor is often a first step on the road to becoming a full committer.
@Abel:
The legal concerns are of course very important aspect. But I believe we might be able to create a work flow that incorporates these IP reviews as a standard procedure. An option might be to have somewhat unofficial, “tainted” repositories that holds unreviewed patches. The IP team could then take these patches and review them, and if they are accepted, push them into a “blessed”, official repository. This is just one possible process, I think we’ll discuss this in more detail at the BoF.
@Mike:
Offline mode is indeed a very nice feature, but I think this is just the tip of the iceberg.
@Scott:
I was wondering whether to propose a more general DVCS BoF or specifically a git BoF. The way I see it git is the DVCS with the most momentum, both in general as well as within the eclipse community. I fear there has been a balkanization of DVCS in the recent years. While choice and competition is a good thing, it tends to divide the attention in situations like these. So rather than have a more general and abstract session I wanted to make this more concrete. I have been investigating distributed source control quite intensively in the last months, and in my humble opinion git is overall the system with the cleaner structure, better feature set and superior performance. I also feel that git is the better match for a project like eclipse. Though I must say that I wouldn’t mind at all if the eclipse community were to choose Mercurial instead. Anything to get us out of the VCS dark ages.
The main objective of this BoF is to make some headway into discussing legal, technical and process issues surrounding the adoption of a DVCS at the Eclipse Foundation. And I think that most concepts and solutions should translate quite well to any other DVCS should the community choose to adopt a different system. I would just like to keep it concrete for now.
So I would prefer option your option b). Though that is not up to me but the EclipseCon organizers. Maybe you could contact them directly and see what they think about your proposal.
Maybe the gerrit review system (http://code.google.com/p/gerrit) enhancing git and the Android development process using both (http://source.android.com/submit-patches) point into a direction how Eclipse could progress from CVS/SVN to git. Such a review system could help to ensure that the rules of the Eclipse development process cannot be broken by contributors who are not full committers.
@Matthias:
That is indeed a good idea. This would keep the barrier of entry low, while still having all the necessary checks in place. Shawn Pearce, who is heavily involved in both egit and gerrit, will be present at at the VCS panel as well as the Git BoF. I am quite interested to hear about his experience with android, and whether such a development process would be applicable and viable in the eclipse ecosystem.