Project Community Enhancements for 2010
I mentioned in a comment last week that — pending Board approval of the 2010 budget — there are a number of items which we’re looking at for 2010 that we at the Eclipse Foundations are pretty excited about. These are some major pieces of work that we are going to be focusing our time and energy on.
There will also be a number of significant programs for the commercial members, but those will be the topic of a separate post.
- Build and Test: The team here is aggressively begging companies for the hardware contributions required to take on more of the build and test requirements for Eclipse projects. If we are successful, we will happily provide additional infrastructure and support for build and test activities for projects. But don’t forget that the hardware is actually only a relatively small part of the total solution here. The resource management that the webmaster team will take on will be a significant amount of additional work for Denis and team.
- Git: Denis and the webmaster team have been working hard on getting read-only git mirrors up and running on eclipse.org. But we really look at this as just the starting point. We view git as the SCM solution of the future at Eclipse and hope to have it up and running for as the main SCM repository for as many projects as possible by the end of 2010. Our reason for doing so is pretty simple. From what we can tell, the use of git at Eclipse is going to make it easier for contributors to make and track changes to the Eclipse codebase. And anything which gets us significantly more contributors is a very good thing.
That said, there are a couple of items that are out of the Foundation’s control that the community will have to help with.
- The CVS Team Provider that has been in the platform for years is really good. In fact, it is so good and so stable that it makes CVS very usable from within Eclipse. For git to gain traction at Eclipse, the EGit Team Provider is going to have to get good, and do so quickly. If we want to see git adopted to a significant degree, my personal belief is that we are going to have to ship EGit with Helios. My guess is that you, the community, are going to have to help make that happen through use, feedback and contribution. (Note that I do not know what the plans of the EGit project are. This is my personal opinion.)
- The Eclipse Foundation doesn’t tell projects what to do. So if git is going to be adopted at Eclipse, the projects are going to have to vote with their feet. In other words, we are going to have to see a number of the large and mature projects bite the bullet and make the transition to git. Because if there is little or no evidence of this within the projects, then the investment by the EMO will be for naught.
- In some ways, the most difficult part of this will be deciding which of the existing SCM systems we’re running to shut off. I personally have a major problem with the idea of running CVS, SVN and git for anything other than a short and constrained period of time. The main reason for this that having multiple SCM systems is a barrier to contribution for the community. If someone needs to learn three different SCM systems to interact with and contribute to three different Eclipse projects, then we have failed our community.
- “Eclipse Labs”: We’re looking at creating an Eclipse Foundation affiliated forge where projects which are based on the Eclipse platform, but are not interested in hosting at eclipse.org can run their projects. There will obviously be some constraints (e.g. only Eclipse Foundation projects can use the org.eclipse namespace, and be part of the release train) but Eclipse Labs will hopefully over time form a powerful complement to the projects hosted at Eclipse.
- “Get Involved”: We are going to be adding some variant of a “get involved” menu item to the left nav for project home pages. We want to make it easier to contributors to understand how to get involved with every Eclipse project, and we want to help projects to learn and follow best practices on how to facilitate more community involvement. Obviously, this may require some additional work for some projects, but the increases in community involvement, contributions and project diversity will be worth it to all of us.
- Artifact Repositories: We want to make it easier for adopters of Eclipse technology to find and consume the great work that’s happening in the Eclipse Foundation projects. For this reason we are going to be looking into what technologies would make it easier to consume Eclipse software. To be blunt, we don’t know what this might be at the moment. It could be Nexus or Buckminster or Tyco or something new from the B3 project. We just don’t know and we won’t be making any final decision for six or seven months. If people are interested in getting together for a BOF at EclipseCon, I think that would be a great way to move the conversation along.
As you can see, this is a pretty significant list of projects for 2010. Denis, Wayne, Ian and their respective teams are going to be carrying the ball on these. So comment at will, but please also consider buying them a beer at EclipseCon 🙂
Life at Eclipse 
Hi Mike
All of those items look great! Especially the build and test machines 🙂 I agree that tooling surrounding new SCMs is important to encourage adoption. Moving to a new SCM is decision that’s up to our PMC. Given that, I would be curious to learn what the Eclipse foundation’s policy regarding retaining history if a project were to move to a new SCM. If we were to move to a new SCM we would need to retain our history, perhaps in a read only copy, so we could continue to build older versions of Eclipse, and allow users to rerun older source builds etc. without refactoring years worth of build scripts. Also, if you were to EOL a SCM, it would be good to know this date, well in advance, so that the teams could factor this into our release plan well it advance. It’s a non-trivial item that requires a lot of planning to implement.
Kim Moir
December 7, 2009 at 6:23 pm
Kim, I promise you that any SCM EOL plan would be communicated very far in advance. In fact, I’m not even sure that we would really need to take a r/o code repo off the servers. Deleting history is a scary thing.
But I think the important point is that we’ve never done this (EOL a SCM) before, so we don’t have any policies. We are going to need the help of people like you to make sure that we capture all of the requirements and create a plan that works for everyone.
Mike Milinkovich
December 7, 2009 at 6:44 pm
Likewise, I’d like to propose that, when moving to git, a project can choose to keep their ancient history where it belongs — in an archive. Some projects have accumulated tons of baggage over the years, and only small portions are relevant today. When is the last time someone has built Eclipse 2.1.2?
Moving to a new SCM would be a great opportunity for older projects to restructure and trim their repository and get a fresh new start.
It’s food for thought.
Denis Roy
December 7, 2009 at 8:20 pm
Denis, that’s what I was suggesting. A read only archive. I wasn’t worried about releases like 2.1.2, but rather code from one or two releases ago.
Kim Moir
December 8, 2009 at 9:55 am
Eclipse Labs is a great idea and initiative. Waiting eagerly to see more information on labs.
Madhu
December 8, 2009 at 12:58 pm
@Madhu – At the moment, we are expecting to announce this at EclipseCon in March.
That’s the downside of talking about a year’s worth of work in a single blog post 🙂
Mike Milinkovich
December 8, 2009 at 4:13 pm
It would be nice if “Eclipse Labs” projects could use some dedicated package namespace, whatever it is. Maybe a special eclipse-affiliated top level namespace or maybe a dedicated sub-namespace in org.eclipse would be possible?
Ralf
December 9, 2009 at 6:33 pm
@Ralf – Yes, we just talked about exactly that topic at the Board meeting today. The org.eclipse namespace is reserved solely for projects hosted at the Eclipse Foundation, so that’s not an option. But we’re thinking of perhaps something like org.eclipselabs. What do you think?
Mike Milinkovich
December 9, 2009 at 7:28 pm
Re: Git and ‘Eclipse Labs’ (a.k.a. ‘EclipseForge’). Another useful bit of community ‘scaffolding’ to
borrow from the Git folks is Gist – a ‘side’ repository to GitHub (backed by Git, of course!) that is
similar to ‘pastebin’. The general idea is that there is a lot of knowledge locked-up in people’s
“favourite 5 lines of code (or configuration)” but no (central) place to put it.
I have entered a ‘Community’ bug 296804 – Eclipse should provide a ‘gisthub’-style “snippet”
repository.
+ Vote’s are welcome!
Mike Norman
Mike
December 14, 2009 at 11:27 am
It would be great to permit usage of org.eclipse.labs.PROJECTNAME package namespaces.
Erdal Karaca
January 13, 2010 at 8:48 am
The Nova theme is great. I love the look of Xtext project.
The recent changes like wiki, improved project home pages an so on are enhancements but I do not think enough.
Eclipse Marketing should put more efforts on the website. I think the easiest way of doing that is to provide some templates and switch to wiki based web site.
I really like to see eclipse adopt a distributed SCM as it is very hard to keep up with your patches especially in the middle Milestone / Integration releases. I think CVS had its time.
For those like who is in love with two – Maven, Eclipse – artifact repositories will be much appreciated.
Last but not the least, being home for a lot of projects Eclipse has done great job, however Eclipse Labs will fill a big gap. I hope we get it soon. Eclipse should also be home for external projects like google-code, sf, etc.
Regards,
Hasan Ceylan
Hasan
February 8, 2010 at 1:19 pm
@Hasan,
Re: Adopting a DVCS, please see the following[1][2][3]. We are well on our way to getting Git up and running. If you want to help, please contribute to the EGit project[4]
[1] http://dev.eclipse.org/blogs/mike/2009/07/16/time-to-git-some-progress/
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=257706
[3] http://dev.eclipse.org/blogs/wayne/2009/12/01/git-at-eclipse/
[4] http://eclipse.org/egit/
Mike Milinkovich
February 8, 2010 at 2:11 pm
I have two wishes for GIT:
+ Have the GIT protocol available on port 443 to avoid Firewall problems (the HTTP protocol is painful slow)
+ Update GIT every hour instead of every day (this is the interval which is used by many others and is a good comprise I think)
Roland
March 3, 2010 at 6:22 pm