Top Level Eclipse project Release Engineering team
Describe yourselves, your project and your relationship to other developers on the team. Consider describing ...
* years of experience in development, doing release engineering, and specifically building Eclipse projects. * how you work, on a good day, or on a not so good day. how does your work change as you ramp-down toward release. * what automation you use and how often you change it. how late in a project you would consider automation changes and how you would know that they work.
The release engineering team consists of Sonia Dimitrov and Kim Moir. We provide release engineering services the Eclipse top-level project (Platform, JDT, PDE and Equinox subprojects). We also manage builds for some of IBM's Eclipse based product offerings.
Eclipse 1.0 was released November 7, 2001. Sonia joined the eclipse release engineering team in early 2001. Kim moved to the release engineering team in late 2003.
Our relationship to other developers on the team is multi-faceted. Some of our responsibilities include
- Implement and test new functionality in the build process. We work closely with the PDE Build and Core/Equinox committers to test new PDE build features, for example grouped builds, versioning, conditioned and packed jars etc.
- Manage the build and test infrastructure.
- Assist developers when they wish add new plugins, test plugins, reorganize features etc. Run many test builds to ensure that the next build will complete successfully.
- Public relations - keep the build team up to date on the build schedule, milestone schedules, changes to the build etc. Often we also serve as the unofficial "greeter" to the team and redirect people to the correct contact person for their area of interest.
- Design and maintain feature structure.
- Constantly trying to optimize our builds.
- Implement new automation tools in our build.
- Testing, testing, testing the build process. And then testing it again.
- Although our process is automated, we do still monitor the builds, especially during milestone weeks. We also encourage quick resolution of build problems. (Gentle prodding.)
- We often provide advice to teams who are trying to build in the "Eclipse Way".
We truly enjoy working with the other developers on the team because
- Everyone is willing to share knowledge and work together to solve problems.
- People care about the code they submit and ensuring that a build is successful.
- They feed us well. (Core team - chocolate, PDE team - cake, UI team - curry).
On a good day, the builds are working, the lab infrastructure is stable and there isn't a crisis that needs immediate attention. This allows us to focus of fixing our bug backlog, testing new build functionality or implementing new functionality. On a bad day, our lab infrastructure has serious problems, unexpected and unavoidable build problems have ocurred. ie. network or power outage, hardware failure, small floods.
Our top priority is to get a build to developers. We also minimize risk of build failure by testing our process from end to end with any change in the scripts or infrastructure. We strive for CRISP builds (complete, repeatable, informative, schedulable, and portable) that incorporate release engineering best practices.
Since we have milestone builds every six weeks, we always feel that we are working toward a release. Of course, there isn't as much at stake with M1 as there is with M5 so the later milestones are much more stressful. During milestone week, we don't usually implement new functionality into the builder because we want to ensure that the builds run smoothly as possible. However, sometimes we need to make late breaking changes in the builder to address a serious bug during milestone week. During each milestone week, we test the newest plugins org.eclipse.releng.basebuilder. (org.eclipse.releng.basebuilder is a subset of eclipse SDK plugins that we use to run a headless build). This ensures that we can move the plugins to the builder as soon as the milestone is released.
As we ramp down toward release, we try try to reduce the magnitude of the changes we make to the builder. Also, by the very nature of the end game, as we move toward the release it requires more approval to submit bug fixes to the build.
Overall, Callisto was a good experience for us. I don't think that we made any special adjustments because we are at the bottom of the stack, don't compile against anyone and we usually release milestones early on to allow others to build upon us :-) I found the mailing list to be an effective means of communication but also spoke with other teams on IM. It was also good to collaborate with other Eclipse project teams and learn how they were approaching problems.
Describe your Callisto experience. Consider describing ...
* special adjustments you made because of your participation in the simultanious release. * tactical communication regarding inbound and outbound bits. * strategic communication with respect to the Callisto planning team.
Issues that arose in Callisto that I would hope that we would be addressed in Europa
- Bug triage - There needs to be more participation in bug triage of cross-platform issues. Very few people subscribed to the Callisto component for bug notification.
- Implementing new and existing build technology across projects - For instance, including packed jars could decrease the bandwidth utilization and significantly improve the update experience for users. However, since it's new technology it takes a while for it to percolate across projects, be tested in the build scripts, and implemented in production. It would be great if more projects implement technologies such as these in an earlier timeframe.
- versioning - There were a lot of questions about implementing qualifiers. Admittedly, it is a complicated topic. However, I don't know if there is a way to diffuse information such as this across projects in a more effective manner. Tutorials etc?
Facilities I wish we had
- More time dedicated to improving our build process
Describe your hopes and ambitions for Europa. Consider describing ...
* facilities you wish you had and how they might work and who you would trust to build them. * precedures that would make your life less stressful or more efficient. also when and how you would escape those precedures in an emergency. * communication mechanisms that would support both routine and exceptional circumstances that are sure to arise as more projects join the release train.