OK, when a thought spreads out more than two tweets, it's time to write a blog entry instead. Ed Merks tweeted from the Eclipse board meeting (I presume) about the board's concern that if Kim Moir got hit by a bus, we'd all be screwed, or something to that affect. And it's true. Kim is a most valuable person at release time for getting the Eclipse train out the door. Without her for the Eclipse Platform, or David for the p2 site aggregation, or Markus for the EPP builds, we'd be scrambling.
So while I don't want to take anything away from the great work they do, I do think it's time to move to a better system where anyone can easily jump into their shoes. Not only that, but I'd like it to be easy for anyone to be able to checkout all the Eclipse projects they need and build their own product from it. I often get questions on the recommended approach to do such a thing and I don't have an easy answer for them.
But there are two technologies that we are currently deploying that can improve the situation immensely. And I am working on bringing both to the CDT. The first is git and the second is Maven with the help of the Tycho plugins. As an example, I'd like to checkout all the source that feeds into the Eclipse C/C++ IDE package and then from the root directory, type 'mvn clean install' and have the zip file come out at the end.
Better yet, I'd like to clone all the source, commit any bug in any of that source on a branch, and do a build to get a test package, or a package I can send to my downstream customers. That scenario happens all the time in open source and git is making it a lot easier to manage your local branch, while making it easier to push changes upstream. And Maven/Tycho can make it easier to send builds downstream.
But it only really works if all Eclipse projects buy in. Maven can be done in parallel with whatever build system they are using so that's not a huge problem. Getting them all to move to git is a bigger challenge. But I see the momentum starting, especially with the Eclipse Platform project discussing moving. So I'm confident we can get there. We just need to show the value the community gets from the significant work that is required to make these changes. And then we can leverage that good work ourselves and build the EPPs at eclipse.org using the same technology.
+1 Xtext is going to switch to Tycho/Maven very soon.
ReplyDeleteDoug your comments are flattering but really it's the entire Eclipse and Equinox team that get the release out. As for committers running the build, we have made significant steps toward this goal in 3.7. We can now run the build on hudson.eclipse.org including tests. The reason that the real build isn't switched to eclipse.org is that a few remaining tests still fail due to infrastructure issues and we needed to get our release out. As well, I haven't had a chance to convert our performance tests to run on foundation hardware.
ReplyDeleteAs I mentioned on twitter, our immediate priorities are to switch to git, and get the remaining bits of the build running on hudson.eclipse.org.
As for Tycho, I have talked to Pascal and there are current limitations to running our build on it regarding how we compile against multiple BREEs. Those issues notwithstanding, migrating to a new build system would be a very time consuming plan item. The PMC must ultimately decide if such a significant time investment would be be worth the opportunity cost of deferring other priorities on our very long to-do list.
The Eclipse platform/build is a unique beast due to the need to compile native C code on over a dozen platforms. Yes, three are most popular in terms of download numbers. If the Board ever decides they want the entire Eclipse build to run on Eclipse hardware, there needs to be some serious commitment to donating/procuring the appropriate hardware/resources to facilitate this transition. My experience trying to get a mac slave at the foundation was that it was a very drawn out and painful process. Everybody is happy to consume eclipse builds, very few people are willing to step up and contribute :-)
Thanks, Kim. You are too modest :).
ReplyDeleteThis is a pretty important strategic item for Eclipse and from what I hear much effort has been spent over the years to resolve it. I don't expect Eclipse Platform committers to have to do it all. There are enough experts in the community and vendors with a vested interest in this that we can at least start working towards the ideal.