Git 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!