Ok, it’s getting tough. Only 9 days left before EclipseCon officially starts. All contributors and committers around me are already swarming around to get the demos and presentations ready – besides fixing bugs for the upcoming M6 build. But why is everybody so excited about EclipseCon? I think the numerous talks are only one side of the coin. Personally the way more interesting part is the come-together of all people you know from bug reports, mailing lists and newsgroups. While it is nice to see each other, it often brings up great discussions about Eclipse technology – especially interesting for me: RAP and E4.

The number of BoFs this year is tremendous. If you’re developing RAP applications or planning to use RAP in the near future, you should definitly visit me and the rest of the team at the RAP BoF. As this is the first BoF for the RAP project we’re really excited to see who’s coming. If you’re planning to attend, why don’t you just add some of your ideas to the list of discussion topics? The intention of BoFs is that you have the chance to talk directly with the RAP committers and give the team the chance to see your standpoints. Take the chance to poke us for all the bugs we didn’t fix yet Or if you’re interested to see any of the long-standing feature requests to be added to the plan – no problem (at least if you have enough beer for the team)! We’re looking forward to some lively discussions – not just as part of the BoF!

Tags: bof, e4, eclipsecon, rap

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!

Tags: bof, eclipsecon, git