I’m at From Developer to Download: A Tour of the Eclipse Platform Build Factory. Kim Moir of the Eclipse Releng team is talking. There’s a nice presentation file if you’re interested in how the build process works.
Interesting – the main build machine for Eclipse is a Apple G5 running Yellow Dog Linux, most likely a dual processor machine. I’m currently running the builds for the company I work for on a dual G4. Seems quite a bit faster than some of the other Pentiums we use for builds. But I think things will really fly on a new Intel Core Duo.
Builds used to take many hours to complete. Now they take one hour. What was done to speed this up? A Master Feature was created. There is also now a Master Root Feature.
I guess builds everything in parallel. The big reason (after User talking to Kim afterwards) is because having one big feature avoids the jar / unjar dance. Jarring and unjarring is quite expensive too do. The root feature also helps with signing jars.
Performance tests used to be inconsistent. To improve consistency, test machines are now “ghosted” (take a snapshot) of each performance test machine so that you are comparing them exactly. They are also isolated from the network so security patches which change the system do not need to be applied.
Best Build Blooper: “Release and Run” – When you have dreams of a warm beach, clear blue ocean and you’re running out the door to catch a plane there. I know this one and because of it, I don’t ever check in code at the end of the day. Especially not on a Friday afternoon. :)
Ha – if someone breaks the build too many times, they hand out a clown nose. I tried to take a pic of Kim and Denis as they had them on, but I’m kind of slow on the camera draw. :)
Update: Avoiding the jar / unjar dance was the big reason how the main Eclipse build was optimized.