Releng of the Nerds

2011 by the numbers

2012-01-16T11:46:00.000-08:00

2011 was an exciting year in the Eclipse community. From my corner of the Eclipse universe, he's what it looked like:

One book chapter, many thanks

I contributed a chapter on Eclipse to the Architecture of Open Source Applications in 2010 and the book was published in May 2011. Thanks to Amy Brown and Greg Wilson, for their long hours editing and providing feedback to the authors of this book. It's a great read! When Greg first approached me about writing this chapter, my immediate thought was "How hard could it be? I live and breathe Eclipse all day". It was much more difficult that I imagined but in the process I learned a tremendous amount and am a better committer for the experience. Many thanks to DJ Houghton and John Arthorne for reviewing my drafts and providing valuable feedback. A special thanks to Jeff McAffer who I interviewed about the decision to switch to OSGi in 3.0 and Steve Northover for his suggestions to make the SWT section into something more pixel perfect. Merci Olivier Thomann for answering my many compiler questions, and Boris Bokowski and Paul Webster for their thorough discussions with me regarding the modelled workbench and dependency injection in 4.x. Also, thanks to Mike Wilson to allow me the flexibility in my job to spend some time at work working on this chapter. I'm excited to see that Amy and Greg are now editing a second volume of this book.

Six milestones, many release candidates, two service releases, and one coordinated release, four streams, thousands of builds, millions of tests
No rest for the committers.

143 bug fixes
I closed about 143 bugs in the releng bucket in the past year. That doesn't seem like much really. I'd have liked to solve more. The largest issues implemented from a releng perspective were shared licenses, code coverage, and the largest work item, the Git migration.

42 Git repos
The Equinox and Eclipse projects migrated all their repos to Git. We now have about 42 Git repos. This involved a tremendous amount of work on the part of the Eclipse team as a whole. There were many whiteboard drawings and detailed discussions about the migration process with John, Paul and a Mr. Gheorghe. There was no Ringo. Thank you Paul for all the huge amount of testing, script writing, and migration of all the ui and e4 repos. Thanks John for your work many sage suggestions on our Git migration, as well as your suggestion to implement the git flow method to simplify our development and build processes. Thanks Andrew Niefer for migrating many of the Equinox and PDE repos, Bogdan Gheorghe for your work with SWT, and Oliver Thomann for testing JDT Core repos. Thanks Tom Watson for your Git advice, having already climbed the Git learning curve while working on the OSGi Alliance repositories. To Dani Megert and Markus Keller, your always fine attention to detail and pointing out areas that could be improved is appreciated. Paul is giving a talk about our migration at EclipseCon 2012 called Let's Git this Party Started. I'm sure it will be insightful and entertaining.

One EclipseCon, two talks, one castle, many great people
I was privileged to attend EclipseCon Europe in Ludwidsberg this past November and present two talks. I thoroughly enjoyed preparing these talks, and even more presenting them. On the Wednesday morning, I talked about our Git Migration, and that evening I gave a talk with John Kellerman about history of Eclipse over the past 10 years. After the second talk, a few people came up to me and said that the talk was so good that it should have been a keynote. That was very fantastic to hear because we really put a huge amount of effort into that presentation. I also had a lot of fun talking to people at our booth where we had posted many pictures of the Eclipse family from over the years. The Saturday after the conference Simon Kaegi, Eric Moffatt and I visited Heidelberg castle. Canada scores very low on the castle index so this was a treat.

You can't buy Eclipse magazines or giant pretzels at train stations in Canada either. I was impressed.

19 blog posts
I didn't have much time to write blogs posts this year. The most popular one I wrote this year was about smashing open source stereotypes.

I'm never sure how popular a blog post will when I write them. It's always a surprise. The comparison of Mozilla and Eclipse build infrastructure I wrote last year still holds the record for most popular (it ended up on reddit).

One marathon, many kilometers of training
How is running related to release engineering? Running keeps me sane when release engineering gets crazy :-) Preparing for the Ottawa marathon in May means that you have to start training at the end of January. Running through snow, ice, wind and rain teaches you there isn't really anything you can't do when you are willing put in a lot of hard work to reach your goal. And when you reach that goal, there's a lot of joy, because you know that you have conquered all the obstacles in your path and emerged victorious.

My sneakers after a 19K training run through deep slush

Open source is really a huge team effort and I had a lot of fun in the Eclipse community in 2011.

Who knows what 2012 will bring?

We're the face of open source

2011-11-22T18:34:00.000-08:00

I had some interesting discussions on Twitter this afternoon.

Wayne replied:

Miles said:

One of the great things about the Eclipse community: that we cooperate on open source projects yet compete on commercial products. This slide from the Eclipse 10 years talk that John Kellerman and I recently gave shows the diversity of the CDT project by company.

Here's another slide where we talked about the fact that there weren't originally enough non-IBM committers on the Eclipse project. I called this "Too much blue in the Eclipse rainbow".

Image ©darrentunnicliff, http://www.flickr.com/photos/darrentunnicliff/4510834607/ licensed under Creative Commons by-nc-sa 2.0

I'd like see a more diverse community at Eclipse and in open source in general. To spread the word that it's a rewarding career and we have a wonderful community. Also, I'd like to find more people to fix bugs :-)

Occupy Open Source: We are the 1%

I don't know if the percentage of women at Eclipse is really 1% but it's pretty low.*

Ian later tweeted

My response was that it would be interesting to focus on the person, where they had come from and what they work and work the technology into the discussion. Show a picture of the person, what their educational background is, how they got involved in open source, and what they work on. I think computer science and open source have an image problem. People think that we software isn't a social endeavour. And yet it is. Hello GitHub. That the work we do doesn't change the world and make people's lives better. No again.

One of the ways to combat stereotypes tell stories from the perspective of the person. How they came to work in open source. The interesting projects they work on. Talks they presented at conferences. What they do in their spare time outside work. Curtis writes code for PDE but he also likes to kayak. Susan works on Orion but also runs an organic farm. Andrew writes Linux tools but he also has interesting travel adventures. Eric works on the next generation Eclipse UI and wins pool tournaments. Tom works on that too, and he likes to ski and hike near his home in Innsbruck. Ian lives in Victoria, works on p2 and plays hockey. Introduce the person, then move on to talk about the technology they work on :-)

Yesterday, Syzmon asked me if me if could use our Eclipse 10 Years talk at a demo camp in Poland. I thought that was fantastic. Our talk delivered in another country, in a different language. Go Creative Commons.

Putting these too ideas together, I thought it would be interesting to have a common slide deck we as a community could use at schools or universities called "We're the face of open source". I think it's important to showcase the different paths people take to get to their careers. And kids need to to see something of themselves reflected in people who work in the industry. It doesn't matter if you're a man or woman, your ethnicity, where you live, if you're gay or straight, have five kids or three dogs. The important thing is that you have a story that you want to share to inspire a new generation to consider contributing to open source.

Thoughts?

Notes
*1)This is not intended to be a statement for or against the Occupy movement. I'm just trying to be funny. YMMV.
2) Standing out in the Crowd talk from OSCON 2009 has interesting numbers about open source diversity and the benefits it brings
3) I'm willing to help put the slide deck together in my spare time outside work. We could use a Google Docs to allow multiple people to edit it. Maybe the slide deck could provide a list of Eclipse mentors that are willing to help out students fix their first bug, browse the source tree etc. These are details. Let me know if you are interested in contributing :-)
4) This would make an interesting EclipseCon talk. Ten Eclipse committers/contributors you should know and why

EclipseCon Europe presentations now available

2011-11-15T11:18:00.000-08:00

My presentations from EclipseCon Europe are now available on slideshare.

The first one is the story of the Eclipse and Equinox team's migration from CVS to Git.

Migrating to Git: Rethinking the Commit

View more presentations from Kim Moir

There were a lot of great presentations on Git migrations such as those by Steffen Pingel and Christian Campo. One thing that I've learned is that the time to migrate is proportional to the size of your code base and history. Someone asked me if we considered just starting in Git without our history. Well, no, but that would have solved a lot of problems. It was also interesting to talk to the EGit team, and meet some of the people working at GitHub. (Thanks for the octocat stickers Kevin!). In honour of Movember, this slide seems appropriate.

Image ©dealingwith, http://www.flickr.com/photos/dealingwith/4295488113/ licensed under Creative Commons by-nc-sa 2.0

The second talk I co-presented with John Kellerman. It's a look back at the last ten years of Eclipse history. I had several people come up to me after the talk and say they really enjoyed it. Thanks! It was fun to look back at Eclipse history and dig up funny pictures and bugs. I enjoyed presenting with John because he talked about the business side and I talked about the evolution of the Eclipse community from a down in the trenches commmiter perspective. A good balance. He has been involved in the Eclipse community since well before my time, lots of great stories!

Has it really been 10 years?

View more presentations from Kim Moir

You can also listen to the talk on FOSSLC website. I love the fact that all the EclipseCon presentations were recorded. I plan to go back to and watch the sessions I missed!

A big thank you to the organizers of EclipseCon Europe for a fantastic conference. I've never attended one before, and was very impressed. Beautiful location, interesting talks, great running paths nearby and of course, the best people. It's great to be able to spend time with people who you work with but never get to see in person, like Ian Bull and Andrew Overholt. It was also great to meet new people at lunch and in the hallways. I talked to some first time EclipseCon attendees who were very impressed with the caliber of talks at the conference so kudos to everyone who presented.

At the IBM booth, we pinned up many pictures of the Eclipse family over the past ten years. It was great to talk to people who visited the booth, especially those new the the Eclipse community. I posted a link to them on my Google+ account. Looking back at them it's amazing to see so many smiling people.

It's hard to believe that it's been ten years. I had a number of people come up to me at the conference and say that they couldn't believe that I had been involved in the community for ten years. Well, I can't believe it either. It reminded me of the moment when I stood up on stage to receive my university diploma and I thought, how could these four years have gone so quickly? I don't know but it's been a lot of fun. By the way, here is a list of other committers who have been involved with Eclipse for ten years or more.

More importantly, there are now over a thousand Eclipse committers today. I'm honoured to work with you all :-)

Presentations on slideshare:
Migrating to Git: Rethinking the Commit
Slideshare: Has it really been 10 years?
FOSSLC recording: Has it really been 10 years?
If you look at the speakers notes, you can see the text of the talk. Most of the slides are just pictures in "Presentation Zen" style.

In open source, all you have is social capital

2011-11-14T05:54:00.000-08:00

Over a month ago, I watched this keynote by David Eaves that he gave at DjangoCon. Yes, I'm way behind on the list of things I'd like to blog about. I blame Bugzilla :-) Also, quite a few people at EclipseCon Europe came up to me and mentioned that they really enjoyed reading my blog. Thanks - I enjoy writing!

David Eaves is a negotiation consultant. He helps people on opposite sides of an issue come to an agreement, and has clients in open data, government, industry, and open source communities. He has done work at Mozilla to help manage contributor engagement and implement measures to keep contributors working in the community.

He starts off by telling the story, that as part of of his work with Mozilla, he thinks that he should submit a bug. He submits his first Thunderbird bug and announces on Twitter or Facebook that he's excited to submit his first bug. To which he gets the reply "I bet it's a duplicate". According to this presentation, 50% of all bugs are duplicates. It may be a duplicate, but this response isn't the best approach to encouraging future participation from a new contributor.

He then says that most open source communities don't have financial capital. They don't have money flowing in to influence people. "All you have is social capital". Social capital consists of the people that contribute to your community and make it successful. In theory, in a corporation, human resources tracks how to retain and manage its people. In open source, we spend very little time managing our social capital or even better, tracking it.

He then continues that one of the mantras of open source is that it's a meritocracy and your coding skills are the key to success within the community. But if you look at people who have spent a lot of time in an open source community and are considered leaders, many of them spend a lot more time working with people and managing their community as opposed to coding. To which he says "We pull people in based on their coding skills, and we promote people based on their negotiation skills". Also, he remarks that nobody tells us that, and that we all stress that technical skills trumpet negotiation skills despite the evidence to the contrary.

He then gives examples of funny or misunderstood Mozilla bugs. He states how it's harder to communicate with people when only via the written word. I find that myself. I've met quite a few people at conferences who I've found to be rude in Bugzilla to only find that in person they seem like a totally different person. Reasonable. Friendly. Helpful. Anyways, since Bugzilla is a written medium he suggests that the best way to interact on it is to ask questions. He states that often people just have a solution in mind as a bug fix and aggressively push their solution where in fact they should ask the user what they want to do in the first place. Also, you should paraphrase and repeat what the user said to gain understanding, acknowledge the problem and advocate for a solution. All great advice!

The next section of the talk discusses the architecture of a community. Fork used to be a four letter word in open source But with the advent of GitHub, it's not, but rather a way to empower the user. It also absolves you from seeking anyone's permission before contributing. He says we need to design our communities to "Architect for cooperation and away from collaboration" It's great if a new contributor can start fixing a problem without the transaction costs associated with interacting with a committer. We can spend our time on other tasks. He also states that we need to empower the lowest people on the stack, such as those triaging bugs. He also remarks that immediately marking a bug as invalid without acknowledgement of the effort required to report it doesn't build community loyalty.

GitHub Octocat

Image ©sunfox, http://www.flickr.com/photos/sunfox/4365495446/ licensed under Creative Commons by-nc-sa 2.0

The final section of the talk described applying metrics to the show what is going on in a project. To measure contributor patches from non-paid staff is a way to measure social capital. To determine why people have stopped contributing. To measure wait time for before a patch is submitted. He also states that it would be interesting to have a repository API and once you attach a patch to a bug, it would update the bug with the anticipated wait time, to set expectations for the reporter. He states that Wikipedia segments users based on metrics and they applies actions, such as suggesting mentors for new contributors.

I think having metrics for new Eclipse contributors would be very interesting. I rarely have people contributing patches to my bucket other than from other Eclipse or Equinox project committers, but I'm sure the metrics would be very interesting for other components. It would also be valuable to determine the reason that people stop contributing, and implement measures to encourage people to continue to their involvement.

He finishes by stating that there needs to be a social infrastructure for the community, not just code. Also, in some cases, you many need to remove people from the community to reduce negative social capital. A great talk, I highly recommend it - extremely informative and funny.

Notes:

David Eaves also blogs at http://www.eaves.ca on open data, open source and other interesting topics.
His keynote is here http://blip.tv/djangocon/keynote-david-eaves-5571777

Excited about EclipseCon Europe

2011-10-31T07:02:00.000-07:00

Ten years ago, we were burning the midnight oil getting Eclipse 1.0 ready to release. I offer you proof

Me stuck behind server rack. Yes, I'm wearing COWS shirt. Please don't judge me.

Today, we're working hard to polish our presentations as we celebrate ten years of Eclipse at EclipseCon Europe. I'm excited to have the opportunity to attend EclipseCon Europe, this will be my first time :-)

I've been preparing two presentations over the past few weeks. The first one is called Migrating to Git: Rethinking the Commit. Here, I'll talk about the process we used to convert our large and historic CVS reposository to Git, the problems we encountered, how our development processes changed, and what advice we can offer other teams that are contemplating this migration.

Image ©venegas, http://www.flickr.com/photos/venegas/5549123/ licensed under Attribution-NonCommercial-ShareAlike 2.0 Generic (CC BY-NC-SA 2.0)

Image ©spool32, http://www.flickr.com/photos/spool32/5045502202/ licensed under Attribution-NonCommercial-ShareAlike 2.0 Generic (CC BY-NC-SA 2.0)

The second talk is a light-hearted look back at the past ten years. I received an email from EclipseCon Europe this morning that stated. "After the Stammtisch, a couple of long-time Eclipse enthusiasts present Has it Really Been 10 Years?." Long-time enthusiasts? Okay, that made me feel old. Anyways, in this talk John Kellerman and I look back at the the last ten years and discuss what what we expected when Eclipse was released as open source, the response we received, what mistakes were made, what surprised us. Fair warning: I have uncovered some embarrassing pictures from our past Eclipse family. I'll be using this occasion to showcase them. If you have any interesting pictures to share, email me and I'd be happy to include them :-) My understanding is that a Stammtisch involves beer so I think people will be in the right mood when they walk into the talk.

Last but not least, I invite you for to go for a run or walk each morning at 7am. We'll meet in the lobby of the Nestor hotel. Sign up for EclipseCon exercise here!

See you soon!

A history of lizard wrangling and other software stories

2011-10-07T11:30:00.000-07:00

I've been thinking a lot lately about open source history. I'm in the midst of preparing material for a presentation that John Kellerman and I will be giving at EclipseCon Europe about the history of Eclipse. Last week an interesting video crossed my twitter feed. It was a talk by Mitchell Baker on the history of Mozilla. Mitchell is the Chair of the Mozilla Foundation and Mozilla Corporation and has been involved in this community for many years. Her title is Chief Lizard Wrangler. That's the best job title I have ever heard. Well, being called an astronaut would be fun too but you get the idea. According to Wikipedia, she's a also skilled trapeze artist. I like learning about people with interesting hobbies.

<p>&amp;amp;amp;lt;p&amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;lt;p&amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;a target='_blank' href='http://vid.ly/3p8p5c'&amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;img src='http://cf.cdn.vid.ly/3p8p5c/poster.jpg' /&amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/a&amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;lt;/p&amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;lt;/p&amp;amp;amp;gt;</p>

In the video, she talks about the history of Mozilla, which started in 1998. She describes the tension between Netscape the corporation and Mozilla the community. For instance, the belief in the Mozilla community that commit rights should be earned and voted on by your peers, not just assigned based on your employer. It's a really interesting to learn about the conflict in those early years at Mozilla and how they worked so hard with very few resources to be where they are today.

One of my favourite lines from the talk is that "Technology alone does not change people's lives. Our opportunity in the browser is to have a product that touches people." Also, she states that the problem with a lot of open source projects is that they are irrelevant to the marketplace and don't treat their users very well. For instance, calling a user stupid isn't going to make their life better. "You need to make a product that is elegant and beautiful and powerful under the covers but that people love." Mozilla has a bit of a different outlook that the Eclipse community because their flagship product Firebox is used by everyday consumers. Eclipse components are consumed by developers in the form of open source packages that the coordinated release provides, but at the same time many people consume components in commercial products that build upon our open source offerings.

Some other memorable lines "UI is always the most contentious issue". Well, at Eclipse we never argue about UI. Wait....hmm..maybe...this bug has a few contentious comments.....

This talk really resonated with me. Eclipse and Mozilla are two well known open source communities with different histories but ultimately both are very successful. I highly recommend taking the time to listen to it.

Happy Ada Lovelace Day from Ottawa!

Hacker History

2011-10-03T17:09:00.000-07:00

I recently read the book hackers: heroes of the computer revolution by Stephen Levy. It looks back at the cast of characters that were involved in the early years of computing, starting in the late 1950s until the 1980s. The word hacker in this context doesn't mean someone that was breaking into machines for malicious intent, but rather someone who is breaking new ground in software and hardware. The book is divided into three sections. The first third of the book concentrates on people writing software at university labs such as MIT, the second third describes people making their own hardware in Silicon Valley computer clubs in the 1970s, and the final third looks at the beginnings of the PC game industry in the 1980s.

Interesting things I learned.

From xckd

LISP was invented in 1958. Old school.
People used to single-handedly write a game and and then sell it to a game company such as Broderbund or Sierra On-line for a royalty on sales. Like 30% of sales. A best selling game could make a young developer very very rich in a short period of time.
Silicon Valley used to be called Silicon Gulch. Silicon Valley sounds classier.
Bill Gates sold an early version of BASIC to a computer club which then copied it and distributed it to their members for free. He then published a letter in a club newsletter that stated "As the majority of hobbyists may be aware, most of you steal your software."...."Who can afford to do professional work for nothing?" A young Bill Gates writing about piracy in 1975. History repeats itself.
Early hackers spent days, weeks even months on end in the lab without showering. They also didn't date much. Coincidence? No.
The process to bring the Apple II to market and the interactions between Steve Jobs and Steve Wozniak were pretty interesting.

The book also talks about the "hacker ethic", which underpins many things that we see in current open source communities today. From the book

"Information should be free.
Mistrust authority--promote decentralization.
Hackers should be judged by their hacking, not bogus criteria such as degrees, age, race or position.
You can create art and beauty on a computer.
Computers can change your life for the better".

This book looks at the technical advancements that these hackers implemented, but is also interesting to see the culture as these nascent communities evolved. Also, it also describes the first computer conferences and magazines. It's also interesting to note the incredible passion and effort that these hackers dedicated to their professional endeavours often had negative repercussions in their personal lives.

Anyways, if you are interested in reading about early computing history, this is a great book. The first computer that my Dad (yes it runs in the family) brought home in the early 1980s was an Osborne , so I felt rather nostalgic reading about the this time period.

Source wikipedia

Busting Build Myths

2011-09-01T17:15:00.000-07:00

Who doesn't love Mythbusters? It must be great to wake up every morning and go to work in a fantastically equipped lab, build things and maybe set off a few explosions. A dream job.

Unfortunately, my lab is filled with aging build machines, not cool toys. When a build explodes I have to pick up the pieces and make it work again. I've never been invited to the White House to talk science while sporting a snappy beret either.

Source Wikipedia: Washington Post blog, credit given to The White House/Chuck Kennedy, The White House/Chuck Kennedy

There are a few myths surrounding builds I'd like to bust. I'll use the only tool I have available to dispel them, my keyboard:

1) My six bundle build is easy. Thus your build is easy too. There is a big difference between building a few bundles and building products, p2 repositories, API tests, tens of thousands of JUnit and performance tests for many platforms. Is running an Apache server in your basement the same as running Slashdot? No. Builds are the same. Scalability issues and complexity.

2) Building with X will solve all your problems. Changing to a different build technology to compile and package your bundles can solve a lot of problems if it has been tested fully and works for all your requirements. But there's a cost to migration. To working out all the bugs and corner cases. Is it worth the transition? Only time will tell. The more complex the build, the higher the cost of migration. Yes, it would be wonderful if we could all run our builds the same way at Eclipse to help our consumers. But this requires a considerable time investment to ensure that everything works. As well, it means forgoing work in other areas to facilitate this transition. It's a tradeoff.

3) Once you get your build working, you never have to change it. As my previous post described, build scripts evolve in concert with the code base. Constantly changing. More code, more tests, more build gymnastics. Building software is like owning a house. You can try to to forgo all maintenance to save money, but your risk long term damage from broken pipes, a leaky roof or mice as the building deteriorates.

Homeowner forgot to visit Home Depot

Image ©graywolfx47, http://www.flickr.com/photos/graywolfx47/4308623603/sizes/z/in/photostream/licensed under Attribution-ShareAlike 2.0 Generic (CC BY-SA 2.0)

4) Nobody in needs to understand how the build works, they just need to push a button. That's great. Until the day before a release when your build fails with a cryptic message about unresolved dependencies. And you have no idea how to fix it. And neither does anyone else on the team.

5) Release engineers are unskilled monkeys. On the weekend, I attended the Software Developer's Summit here in Ottawa. Interesting conference and it was great to meet some new people. In the afternoon, there was a meeting to discuss the long term build support with Eclipse foundation staff and other interested parties. The term "monkey" was used by several participants as a colloquial expression for a release engineer. I don't think it meant to be a malicious expression but at the same time, I found it interesting. Many developers have limited knowledge of how builds work, to them it's a big black box. Monkeys. Big black box. Hmmmm. This sounds familiar.

Let's pretend these apes are monkeys.

Source: Wikipedia. Interpretations of 2001: A Space Odyssey

Since we release engineers understand how the black box works, maybe we're not the monkeys :-)

What other build myths are out there?

Research, Release Engineering and ROI

2011-08-31T19:16:00.000-07:00

I recently read some academic papers that quantify some release engineering practices in open source communities. Very interesting.

The first one, "An Empirical Study of Build Maintenance Effort" (PDF), looks at how the time spent maintaining the build impacts the developers in a project. It examines build coupling which refers to the how often changes in source code require changes in build code, as well as build ownership, which is the proportion of developers on the team who are responsible for maintaining the build. The projects studied were ArgoUML, Hibernate, Eclipse (SDK), Jazz, GCC, Git, Linux, Mozilla, PLlot and PostgresSQL.

Here are some snippets I found interesting in this paper. Note that when they refer to "Eclipse-core" they mean the Eclipse project's build. In this paragraph, they are talking about build coupling and how to reduce it

"In Eclipse-core, the coupling is reduced to 16% and in Jazz the observed coupling is a mere 4%. Eclipse-core and Jazz both leverage the automated Eclipse Plugin Development Environment (PDE) build technology. ..... Since the developer must only maintain the high-level build.properties file (via the IDE), the daily build maintenance is reduced".

Thank you PDE family. Dynamically generating Ant scripts at build time to compile and package our bundles makes us look good when compared with other open source projects.

"Other researches have found that the Linux build engineers have spent a considerable amount of time to make their build system as simple as possible for developers, as the expense of a very complex and hard to maintain core build system machinery. "

People always assume that writing software is hard, but for some reason building software should be easy. Build systems are complex beasts and obfuscating the complexity for the user is just as difficult as it might be when writing a full scale application. Writing good software is difficult, and so is constructing an elegant and effective build system. It's just a different skill set.

"Up to 79% of source code developers and 89% of test code developers are significantly impacted by build maintenance, yet investment in build experts can reduce the proportion of impacted developers by 22% of source code developers and 24% of test code developers."

So it looks like if you hire a release engineer and the productivity of your developers will increase. You would buy a new machine to make the build faster, why not hire a fantastic release engineer and make the build better? The numbers indicate an great return on investment.

Building complexity

Image ©algonquin_college, http://www.flickr.com/photos/algonquin_college/4971004199/in/photostream/ licensed under Attribution-ShareAlike 2.0 Generic (CC BY-SA 2.0)

The second paper of is interest is entitled "The Evolution of Java Build Systems" (PDF).

Again it looks at open source build systems that use either Ant (ArgoUML, Tomcat, JBoss, Eclipse-core) or Maven (Hibernate and Geronimo). The authors find that as the number of source lines of code being built (SLOC) is strongly correlated with the number of build lines of code (BLOC).

"Similar to Lehman's first law of software evolution, build system specifications tend to grow over time unless explicit effort is put into refactoring them."

and

"The Halstead complexity of a build system is highly correlated with the build system's size (BLOC), indicating the BLOC is a good approximation of build system complexity".

Lots of build code means increasing complexity. If you are only building a few bundles, your build is easier to understand. Makes sense.

From their analysis, they concluded found that both Ant and Maven based builds evolved in similar fashion.

I like this sentence

"Despite the crucial role of build systems and their non-trivial maintenance effort, software engineering research rarely focuses in them".

I'd like to thank the authors for conducting this research and look forward to reading more in the future. Build systems are complex systems and I welcome the efforts of these researchers to quantify way they can be improved. And it's extra special when they look at the projects that we work on every day!

References:
It will never work in theory
Queens University Software Analysis and Intelligence Lab

Open source: She loves you, She loves you not

2011-08-29T12:33:00.000-07:00

Working in an open source community is great, but there are also some disadvantages. From my admittedly narrow world view as a committer working in the Eclipse community as an employee of a large corporation, here are some of my observations.

Image ©emzee, http://www.flickr.com/photos/emzee/162362897/sizes/z/in/photostream/ licensed under Creative Commons by-nc-sa 2.0

Things I love about working in open source

The people you meet are amazing and enthusiastic. It's is a privilege to work with such a group of talented and thoughtful people.
Instead of non-disclosure agreements, we're free to talk about everything we work on. Since everything is open, there are tremendous learning opportunities. This inherent openness means university researchers write papers about our work. Interesting!
Open source software is used by our consumers in unique ways. When Jeff Norris gave his keynote at EclipseCon 2010 on how Eclipse was used to monitor robots on Mars, it was extraordinary to think that we as a community had contributed to something that was literally out of this world. And when he said thanks to the committers during his talk, it was a very proud moment for us all. There are many other examples of ways in which Eclipse is used to extend our knowledge of the world(s) around us.

Image ©owlbookdreams, http://www.flickr.com/photos/owlbookdreams/3721505610/ licensed under Creative Commons by-nc-sa 2.0

Some things I don't love about working in open source

Many people complain but don't contribute. They consume the code we craft, complain about how its written, but are loathe to roll their sleeves up and write a useful patch.
We are constantly starved for resources, whether it be people, or new hardware. There are too many bugs and not enough days :-)
My gender is an outlier in our community.

Ten years ago this week, I started working in at a small company called Object Technology International (OTI) as a system administrator. I was asked by Jeff McAffer to install a server called dev.eclipse.org that would act as a CVS and bugzilla server for a project that they were going to open source called Eclipse. I said something like "Open source, that's great. Just like Linux". To which Jeff replied along the lines of "Well, I don't think it will be as popular as Linux, but we'll see what happens". And the rest as they say, is history.

What do you love about working in open source?

Kill Build: Vol. 1

2011-06-03T13:21:00.000-07:00

Here are some of the ways I've seen a build killed during my years as an Eclipse committter.

1. Lightning. Ottawa has tremendous thunderstorms in the summer. What also happens during the early summer? Our coordinated release. One summer, a transformer next to our office was hit by lightning. Boom. No power for about 12 hours. Bye bye build.

Image © ViaMoi, http://www.flickr.com/photos/viamoi/3338093351/ licensed under Creative Commons by-nc-sa 2.0

2. Ice. The air conditioner in our lab filled with ice and ceased to function. The machines in our build lab then overheated and shut down.

3. Flood: Our lab's air conditioner leaked the resulting water and flooded the lab. The build was relegated to a watery grave.

Image © thirsk, http://www.flickr.com/photos/thirsk/840616475/ licensed under Creative Commons by-nc-sa 2.0

4. Random loss of power. A committer plugged in a space heater in her office which tripped a circuit breaker and killed the power in our build lab. Or the total and intermittent loss of power from the Ottawa Hydro. In the end, the results is the same: a dead build.

Image © ViaMoi, http://www.flickr.com/photos/viamoi/3339707547 licensed under Creative Commons by-nc-sa 2.0

5. Hardware self-destruction. The eclipse foundation's power supply for a disk array sparked and brought down the switching gear. Dying switches, UPS's and drives have also wrought havoc.

6. Permission issues: Permissions problems on the filesystem caused committing to the repository to fail. Or the signing process to time out. Or both.

7. Network timeouts aka no network love.

Image © zoso_tc, http://www.flickr.com/photos/zoso_tc/3024964999/ licensed under Creative Commons by-nc-sa 2.0

8. Human Error: The usual suspects compile errors, uncoordinated changes across projects, problems in builder itself, corrupted jars etc. have sent many builds to an early death.

9. Upgrades invoke the unexpected. Changing a ssl certificate unleashed shenanigans. An simple upgrade of a test machine caused failures.

Image © waferboard, http://www.flickr.com/photos/waferboard/5321533361/ licensed under Creative Commons by-nc-sa 2.0

10. Not respecting resource constraints. Consuming all the disk space, CPU, and bandwidth available is a fine way to finish off a build.

How your builds failed? Any exciting ways I've missed?

Looking toward the Indigo finish line

2011-05-28T13:24:00.000-07:00

This week, the Eclipse and Equinox projects released 3.7RC3. For the past month, we have been in end game mode. This means that make release candidates available about once a week, each with progressively stringent requirements to release a fix. All code changes require approval as follows

RC1 - Another committer must +1 your bug before you can submit a change.
RC2 - Two committers must +1
RC3 - Two committers and a component lead must approve.
RC4 - Two component leads must +1 your bug. A component lead can veto your change. Steve Northover coined the term intergalactic approval for a bug fix at this stage of the game.

Image © lrargerich, http://www.flickr.com/photos/lrargerich/4999906554/ licensed under Creative Commons by-nc-sa 2.0

During this entire period, documentation changes can go in without approval. During RC3 and later, all code changes must be announced to our project's release engineering mailing list to communicate to the other committers that you intend make a change.

There are some interesting parallels between the Eclipse end game and long distance running. This weekend, 40,000 runners and 100,000 spectators will participate in Otttawa's Race weekend. The week before their race, athletes participating in the longer distances will taper their runs. In other words, their training mileage drops significantly so that they're well rested for race day.

Image © Gamma-Ray Productions, http://www.flickr.com/photos/29143375@N05/3574211684/ under Creative Commons by-nc-sa 2.0

At Eclipse, the process is similar. We taper our bug fixes as we approach release day. Eclipse is known for it's stable and predictable releases. At lunch yesterday, my committer colleagues remarked that some of their dependencies (not Eclipse projects) just release at regular intervals and and don't have a ramp down process. Other projects release occasionally and then don't have a release for several years. No predictable release schedule. At Eclipse, we are predictable and stable. Some may call that boring, but it allows other projects and products who depend us to consume us at regular intervals. Eclipse 3.7 is especially stable this year given that many committers have been busy releasing innovative new features to Orion and Eclipse 4.1.

We also have weekly test days where the committers and community test the builds and ensure that there aren't any regressions that were recently introduced. For example, here is the PDE team's test plan.

In addition to reducing the amount of changes we release to the build, to ensure the stability of the code base, this tapering of bug fixes and the associated approval process also ensures that other committers have a chance to evaluate our patches. This sanity check ensures that the fixes are both significant enough to warrant releasing to the build at this time and technically correct. I can't speak for other committers, but at this stage of the Eclipse release, we are all a bit tired. So it's good to have several sets of eyes looking at your patch.

Committer after Indigo release

Image © kaibara,http://www.flickr.com/photos/kaibara/4068996309/ licensed under Creative Commons by-nc-sa 2.0

At this stage of the game, only serious bugs are fixed. It's not worth causing ripples within the code to fix a minor bug only to find out after the release is available that this fix had intended consequences.

Image © Marc Dezemery, http://www.flickr.com/photos/mdezemery/295687769/ licensed under Creative Commons by-nc-sa 2.0

What process does your project use to ensure that your code base is ready for release?

Further Reading
Eclipse 3.7 Endgame plan

SDK code coverage with JaCoCo

2011-03-14T15:13:00.000-07:00

Today, I had to pleasure of closing bug 241254 which has been open for over two years. It was a request to run a code coverage tool against the SDK during the build.

We used JaCoCo which is an EPL licensed code coverage library brought to you by the same team that created EclEmma. Why did we chose JaCoCo?

Help from JaCoCo committers. At EclipseCon 2010, Marc Hoffman (JaCoCo committer) indicated to Olivier Thomann that he was interested in helping us to implement JaCoCo in our build.
Performance. Other code coverage tools made the JUnit tests take significantly longer. Our tests take long enough to finish as it is! Olivier tested JaCoCo and found that it only took the JDT core tests about 2% longer to complete with JaCoCo enabled. Our 68,000 JUnit tests take about seven hours to run in parallel on three platforms. The JDT Core tests comprise 37,000 of these tests, thus we estimated the impact of running JaCoCo during the build would only increase the test run by about eight minutes.
Classes are instrumented on the fly and and remain untouched after the code coverage data is generated. Other code coverage tools require you to instrument the classes for code coverage. Given the huge code base of the SDK, this didn't seem like a feasible alternative.
JaCoCo reports look awesome.

How did we implement JaCoCo in the build?

Olivier tested an earlier version of JaCoCo and worked with the JaCoCo committers to address some issues. Once these issues were resolved, we opened IPZilla bugs to consumed JaCoCo as part of the Indigo release.
The Eclipse SDK JUnit tests are run with the assistance of a project called org.eclipse.test. An Ant script called libary.xml is used to invoke the test suites for each test bundle. We added the JaCoCo agent and Ant jars to a new library directory of this project.These jars are then added to the extraVMargs property when the tests are run. The libary.xml also specifies the output directory of the coverage data (*.exec files).
When the tests are run, corresponding exec files are created for each test bundle.
We modified the test.xml that is used to run all the tests suites to generate a code coverage report upon completion of the JUnit tests. All the *.exec files are merged into a single file. A coverage report for each bundle in the SDK is run. (excluding Orbit and doc bundles as well as fragments). The Ant for the report generation looks like this:

One problem that we encountered was that that JaCoCo report task was running out of heap space when the source files were passed to it as as zipfileset instead of a fileset. This problem occurred especially when attempting to generate source reports for large bundles such as jdt.core. We overcame this problem by unzipping the source bundles into a temporary location and passing the fileset.

In addition to code coverage percentages, the report generates html of the source files that highlights the code coverage within the code itself. For example:

All this information consumes about 1GB per build. (Sorry Denis and Matt). Thus I have only enabled it for our weekly integration builds, and the data will not be sent to the mirrors.

The code coverage reports for 3.7M6 are now available. Check out your favourite Eclipse SDK bundle!

References
JaCoCo project
JaCoCo mission and design goals
JaCoco Ant tasks
Bug 241254 - run code coverage tool during build
Marc Hoffmans's JaCoCo talk at Eclipse Summit Europe 2010

Thoughts on Making Software

2011-03-01T12:13:00.000-08:00

My husband (aka Mr. Releng) and I were driving home from his office party in mid-December and had the following conversation.

Me: A publicist from O'Reilly emailed me today and asked if I would like a free copy of Making Software.

MR: Huh. Why did they offer you a free book?

Me: I don't know. I mentioned to one of my Eclipse colleagues on Twitter that I thought it would be an interesting book to read. Also, one of the editors is Greg Wilson, who's also the editor of the upcoming The Architecture of Open Source Applications. (I contributed a chapter on Eclipse to AOSA).

MR: Next time, mention on Twitter that you'd like a free car. What's the book about?

MR: Free car from Twitter? Don't get your hopes up. The book investigates the evidence that supports common software engineering practices. In medicine, a clinical trial is conducted to see if a new drug has a statistically significant effect compared to placebo or an existing treatment. The same evidence based principles can be applied to software engineering to determine if TDD or Agile methods are actually effective. I've always thought that there was a lot of shouting but scant evidence to support different software development practices.

MR: Yeah, undergraduate computer science is engineering. Graduate level computer science is math.

From xkcd

As you may have guessed, I'm married to a mathematician.

In addition to being a fan of open source, I also enjoy reading about different scientific disciplines. I love reading scienceblogs and have read many great books over the past year about evidence based medicine. So when I heard that there was a book available that examined what software engineering practices actually work, I was intrigued.

In any case, I finished reading it recently. It was very interesting and I learned a lot! The book is split into two sections. The first section dealt with different research methods. For instance,

How to conduct a systematic literature review
Empirical methods that can be applied to software engineering studies and why software engineering is inherently difficult to measure quantatively.
How to decide on the papers to include in a meta-study.

From xkcd

The second half of the book examines the evidence for different questions in software engineering. For instance:

How do you measure programmer productivity? Are some developers really an order of magnitude more productive than their team mates?
Does test driven development result in better software?
What's the cost of discovering a bug early in the development cycle versus after the product has shipped?
What working environment (cubicles/offices/open concept etc) are the most productive for software developers?
Is there a measurable difference in software quality between open and closed source software?
What are the reasons for the low proportion of women working in the software industry?
Does the use of design patterns improve software quality?
How do mine data from open source repositories for your own studies (Chapter 27 uses the Eclipse project as an example :-)

All in all, I found it a very interesting book that examined the actual empirical evidence to support or refute some of the sacred cows in software engineering. I think this this is a refreshing step forward for our profession. If there aren't numbers to support that the way we work is effective, shouldn't we alter our path to use better methods?

Further reading
Software Carpentry: Empirical results

As an aside, some great books on evidence based medicine are
Bad Science by Ben Goldacre
Trick or Treatment by Simon Singh and Edzard Ernst
Snake Oil Science by R. Barker Bausell

Eclipsing the build

2011-02-08T12:07:00.000-08:00

A plan item for 3.7 is to transition the Eclipse and Equinox build process to run on eclipse.org hardware. Why may you ask, isn't this the case today? Two reasons:

1. Until recently, the Eclipse foundation didn't have hardware to support our requirements of running tests on multiple platforms (Windows, Mac, Linux).
2. There wasn't a plan item to transition our build to eclipse.org until 3.7. You may think that we open source developers are happy hippies who have the freedom to work on the bugs that interest them :-). The reality is that I prioritize my bugs as follows:

Fix bugs that cause the build to fail.
Fix bugs that block other committers from moving forward with their work or are necessary for legal reasons.
Plan items
Everything else

I was going to write a post describing the progress migrating to eclipse.org hardware but I thought it would be a good idea to give you some background regarding how the Eclipse and Equinox project's build works today.

The Eclipse build creates SDKs for 15 platforms.

A graphical representation of the 15 platforms we build (os,ws,arch)

We use fragments to define platform specific code that is associated with a host bundle. In some of these fragments, there's C code that needs to be compiled on the platform specific hardware to create binary libraries. For instance, the SWT and equinox launcher fragments are examples of these artifacts. We have about seven machines to compile the libraries for these 15 platforms, as some are cross compiled. The SWT and Equinox team have hudson instances, which connect to all these internal IBM servers, compile the C code, and commit the resulting libraries in binary form to CVS at eclipse.org. This part of the build isn't transitioning to eclipse.org.

A simplified description of the existing Eclipse build that produces the artifacts that are available for download on eclipse.org is shown below. Essentially, once a build is launched from cron, the build scripts check out all the code from eclipse.org to the IBM build machine which compiles the bundles. These bundles are copied to eclipse.org to be signed, then copied back to the IBM build machine to be assembled into a p2 repo, from which we create SDKs to run the tests. The zips, repos and test results are rsynced to eclipse.org.

Once we get the issues worked out with the new Hudson slaves to run tests, all the JUnit tests will run on eclipse.org hardware. Eventually, we hope to run the performance tests there once we have sufficient hardware.

Advantages of moving the build to hudson.eclipse.org

The build process will be more open and other Eclipse and Equinox committers will be able to start a build. Today, I manage the crontab of the build machine.
Fewer issues with network timeouts due to the fact that the eclipse.org filesystem is local to Hudson.
Hudson has a rich feature set and many plugins to extend it.

Disadvantages

Like kindergarten, we'll have to share the filesystem and machines with others. Today the build runs on dedicated machines and thus we don't have resource constraint issues from other teams. (The build process itself isn't faster at eclipse.org because of these resource constraints, but the tests are because at the moment we are the only team using the Windows and Mac test machines.)
Can't hack and slash the build on the the command line to rerun a single test suite or restart the build manually.

In a future post, I'll describe the process to transition our builds to run on eclipse.org and the obstacles that we have overcome.

How can you help? Consider donating to Friends of Eclipse.

References

Build at Eclipse.org

Graphics thanks to open source clip art

Servers
Database
iMac
Server cabinet
Tower
Database

Implementing shared licenses with 3.7M5

2011-01-28T12:20:00.000-08:00

This is the best Eclipse license I've ever seen.

Image © chriscardinal, http://www.flickr.com/photos/disatasu/3243844762/ licensed under Creative Commons by-nc-sa 2.0

Conversely, dealing with license files in Eclipse features is a bit painful. Today, each time the Eclipse license changes, you need to copy the new license files to your features. The license files included in the Eclipse SDK are highlighted below:

These same files are included in the 46 features that the Eclipse and RT Equinox project builds. This is very tedious to update when the license files change. Lots of copy and paste. The license text also appears in the feature.properties.

In Eclipse 3.7M4, the PDE and p2 teams added support for shared licenses.

The license files will be copied from the license feature to the feature that refers to it. In 3.7M5, I modified our features to use this shared licenses. For instance, the beginning of the feature.xml for the Eclipse SDK now looks like this:

To implement this, I followed these steps.

1. Create a license feature. This feature doesn't include any bundles or features. It only stores the license files which its build.properties reference. The feature.properties has only two properties - the licenseURL and license.

2. Update the existing features to reference the license feature. Remove the license files from these features. Remove the references to the license files from your feature's build.properties. The values will be inherited from the build.properties of the license feature. Remove the name and values of licenseURL and license from the feature.properties. These will be included from the license feature. Ensure that you don't have duplicate properties in the feature.properties of the license feature and feature your are updating. This will cause a build failure.

3. Update your map files to include to the new feature. You don't need to nest the feature in another feature to fetch it, this happens automatically. For example, this is where our license feature is located

feature@org.eclipse.license=v20110121,:pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse,,org.eclipse.sdk-feature/features/org.eclipse.license

4. Run a test build. Fix typos until you have a clean build. Verify that all your features still include the appropriate license files.

There isn't an IU for the license feature included in the p2 repository. The license text is included in the metadata.

Note that you'll need to build with 3.7M5 bundles. There was a bug in the 3.7M4 bundles that prevented shared licenses from working in generated source features.

The advantage of this approach is that when the license files are updated, we'll only need to update the license feature. We'll also have to increment the versions of the license feature in the referring feature, but that's a simple search and replace.

Some other implementation details: I could have also stored the copyright information in the feature.properties of the license feature. However, the copyrights of our features are not identical, so I didn't choose this approach. This may be useful for other teams.

Thanks to the PDE and p2 team for implementing this!

Further references

Bug 306818 - Improve license support in p2.
License mechanism description in wiki
Bug 332662 - Adopt new feature that allows to share the license file

Revert to an earlier p2 profile from the command line

2011-01-24T13:02:00.000-08:00

Today, we're running builds toward 3.7M5 for the milestone that will be available Friday, January 28. This morning I updated to our latest integration build from the repository. Unfortunately, one of the bundles had a compile error which was serious enough to cause Eclipse to crash on startup.

If you want to revert your installation to a previous version, this is easy to do from the UI. Chris describes this here.

However, if you can't access the Eclipse UI, reverting becomes a bit more complicated. The online help illustrates how to use the p2 director application to revert your install to a previous profile state.

The list of profiles available in your Eclipse install are located in your profile registry. The highlighted profile id below reflects my working installation from last week.

To revert to this profile, I downloaded a new build, extracted it to a directory and ran the following command

C:\N20110122-2000\eclipse\eclipsec.exe -application org.eclipse.equinox.p2.director -repository http://download.eclipse.org/eclipse/updates/3.7-I-builds -revert 1295719004390 -destination c:\I20100309-0809\eclipse -profile SDKProfile -bundlepool C:\I20100309-0809 -p2.os win32 -p2.ws win32 -p2.arch x86

Operation completed in 68759 ms.

My install was reverted to the previous profile and I could once again start Eclipse.

Hudson best practices and Eclipse

2011-01-19T17:31:00.000-08:00

One of the plan items for Eclipse 3.7 I've assigned is to migrate the Eclipse and Equinox build to run on the Hudson installation at eclipse.org. So I've spent a lot of quality time with Hudson lately. (Soon to be called Jenkins).

Today, I attended a webinar about optimizing Hudson in production hosted by Kohsuke Kawaguchi of CloudBees. Since my handwriting is similar to the last slide in this Oatmeal cartoon, I thought it would be better to jot my notes down in a blog post. As I was listening to his suggestions, I thought about how his seven best practices apply to our use of Hudson at Eclipse.

1. Backups

Backup your Hudson install to protect from disaster and accidental configuration changes.

Image © davemorris, http://www.flickr.com/photos/davemorris/2395980976/sizes/z/in/photostream/ licensed under Creative Commons by-nc-sa 2.0

$HUDSON_HOME on the master stores everything that needs to be backed up. The slaves doesn't need to be backed up.
Live backups are fine as configuration changes are atomic
In addition to the backup of the configuration, a backup of the filesystem is necessary to provide consistent snapshot.
Backups are great but can you restore? On a regular basis, try restoring your hudson configuration and starting up a test hudson instance with the restored hudson.war file.

2. Disk

Prepare for disk utilization growth
Space is more important than speed when ordering new drives
Plan for expandable disk volumes
If it's too late, symlink is your friend

3. Use native packages

For instance, *.deb, *.rpm. Easy to update and install, and they include init scripts.
Configuration is stored in /etc/default/hudson and /etc/sysconfig/hudson
Existing $HUDSON_HOME can be migrated
Native Windows package is a work in progress

@Eclipse: Backups and disk configuration are managed by the webmasters, along with upgrading and installing hudson.

4. Distributed builds

You will grow beyond a single system
Increasing load on a single machine is not the only issue
It's cheaper to grow horizontally (additional machines) versus vertically (more memory and CPUs on a single machine)
It's also good to have isolation between build processes in case you want to diversify the test and build platforms
Let master launch slaves via SSH or DCOM. This makes it easier to keep the cluster up and running.
SSH public key authentication makes it easy to connect to slaves on disparate platforms.

@Eclipse: Yes, we have distributed builds and several platforms available for test purposes.

5. Labels

Treat build machines like livestock, not like pets

Image © davegroth, http://www.flickr.com/photos/davegroth/9107888/sizes/m/in/photostream/ licensed under Creative Commons by-nc-sa 2.0

Build machines should be interchangeable
Don't tie builds to a specific build machine, unless there are platform limitations. This approach will yield better resource utilization and less downtime. Queued builds can use the next available machine instead of waiting for a specific machine.
When using labels for your Hudson slaves, name them to reflect their capability. For instance, if the slave is Mac or Windows hardware, the label should reflect this.
If there is a real reason to limit build to run on a single machine (such as wanting to run platform specific tests), tou can use boolean expressions with labels. For instance, this Hudson job shouldn't run the slaves running Mac or Windows

@Eclipse: We use label our build machines as livestock. No pets for us. However, I'm quite envious that the Mozilla foundation has adopted red pandas (firefoxes).

6. Invest in a good URL

By default Hudson runs on port 8080. This is difficult for users to remember.
Use the host's alias instead of the machine name. Thus if the machine names changes, the users won't have to go to a new URL.
Share port 80 with other applications using Apache reverse proxy with which will also allow you to run Hudson as a non-root user.

@Eclipse: https://hudson.eclipse.org is short and simple.

7. Try to keep the build records under control.

Discard old build records if you can
Removing old builds reduces start-up time and memory usage.
Settings are on a per-project basis. For instance, here are settings for one of my Eclipse builds.

@Eclipse: Yes, we do clean up old builds. Also, the webmasters have created a cron job to send a friendly email every week listing of the Hudson disk utilization to remind the release engineers to clean house.

The slides are available here and obviously provide a lot more detail than my short summary. If you're interested the best practices for configuring Hudson for a production environment that has room to grow, this presentation is provides very useful suggestions.

Smashing open source stereotypes

2011-01-14T06:44:00.000-08:00

The Wall Street Journal published an article yesterday where it described the open-source software movement, whose activists tend to be fringe academics and ponytailed computer geeks. This is one of the many unfortunate stereotypes surrounding open source that I've heard over the years. Let's break some of those down.

1. Open source is a fringe movement.

Open source builds mainstream software. I work all day long contributing to open source software, as do many of my colleagues. Why do corporations pay us to contribute to software that doesn't have a price tag? It's in their self-interest to have employees improving the open source software that underlies their commercial offerings. Here are some of the fringe groups involved in Eclipse.

Source: Eclipse Foundation Members' Meeting Q4 Update December 16, 2010

These unknown companies are members of the Linux foundation.

2. Open source is not professional.

At Eclipse, we ship our software on time every year. We've done that for seven years. That's professional.

Source: Ian Skerrett: The Helios Train has arrived

3. Open source contributors are loners sitting in their parents' basement working on arcane bugs.

Nope. Open source is very social. We interact on IRC and twitter. We attend democamps, learn about new projects and build new businesses. We speak at conferences. The software we work on makes a difference in the world. It helps monitor robots on Mars, manages trains in Switzerland and models chemical reactions.

Source: Madhu Samuel: Eclipse Democamp Bangalore 2010

4. Open source developers aren't in good physical condition and don't have interests outside of work

Again, a stereotype that has been proven wrong. We ran 570K at EclipseCon 2010.

Open source contributors run marathons, bike, curl, swim and play soccer or hockey. In fact, you can order an Eclipse bike shirt.

We also volunteer at schools and raise money for charity.

5. Open source contributors are always male.

Source: Miriam Ruiz: Women in Free Software

Wrong again.

We may be a small minority, but here's hoping that these fine female role models will inspire a younger generation of women to consider the amazing career opportunities that open source has to offer. Two generations ago, female doctors were rare. Today, women are over 50% of new Canadian medical school graduates. So, may borrow a phrase from a recent campaign, it will get better.

What other open source stereotypes would you like to smash?

Thoughts on Being Geek

2011-01-05T04:36:00.000-08:00

Sitting on the plane travelling to Nova Scotia for the holidays, I read Being Geek: The Software Developer's Career Handbook by Michael Lopp. I've wanted to read this for a while so I was happy to finally have some time to do so.

It was a very informative and funny book, especially for someone like me who has spent a long time working in the software and IT services industry. Some key points it covered:

You are responsible for your career. Don't depend on your manager or HR. They are looking out for their own interests.
The importance of mentoring and having a career plan.
How to negotiate your salary and benefits for a new job, and how this calculation should be altered if you are looking to move to a start-up versus an established company.
Evaluating organizational culture outside the boundaries of hierarchy. Where is the informal power within an organization?
I really liked the chapter entitled "Your People" on the art of networking and the importance of connecting with people in your community face-to-face and getting to know them better. As I read this I thought, my people are the Eclipse family.
Strategies for dealing with different types of managers and co-workers.
How to decide if you want to be a manager.
Dealing with a crisis situation such a major bug just before the ship date.
The downsides of working in our industry.

As an Eclipse committer, this quotation from the chapter on selecting the tools to use as a developer made me laugh.

"Yeah, I know all about the glory of integrated debugging, and I see all you Eclipse guys having a ball, but what I have found in many years of developing is that embracing fancy tools means tinkering with tools to get them to behave how you want."

-Michael Lopp, Being Geek

There's something to be said for simplicity.

My only criticism about this book is that the example software developers in the book were overwhelmingly male. There were very few female software developers if any used to as characters in his stories. Legend has it that they do exist. All the examples of women in the book seemed to be in product marketing or similar roles.

Anyways, if you are interested in a thought provoking book about strategies for managing your software career this is definitely a good one.

Get your bundles back

2010-12-06T04:30:00.000-08:00

I tried to update to the latest integration build last week. I couldn't because I had accidentally updated to a nightly build at some point. This problem wouldn't happen to most users because only the Eclipse and Indigo repositories are defined by default in the SDK. I have many repositories defined in my install because I'm always testing bugs in different test repos.

Some background:

Eclipse bundles have four part version numbers. Major.minor.service.qualifier. With a nightly build, the qualifiers of all our bundles is replaced with the build id. For example, here's a subset of the bundles from a recent nightly build. Note the qualifier is always N20101201-2000.

With an integration build, the qualifier of the bundle reflects the CVS tag that the developer submitted to the map file. Looking at at subset of bundles from the latest integration build, note that the p2.garbagecollector bundle has a qualifier of v201011-2100.

Since the first three segments of the bundle's version match, and N > v, the bundles from the nightly build always sort higher. This caveat also extends to the IU of the product id, in my case, the org.eclipse.sdk product id. Since I had accidentally upgraded to a nightly build, I couldn't update to any future integration builds because it's bundles will always sort lower.

No problem, I thought. I'll just revert to an earlier install. That's one of the many things that I love about p2. Because p2 stores your previous profiles in the profile registry, you can revert to a previous state of your installation.

What's a profile? A profile contains properties defining the “environment” such as operating system, windowing system, architecture and install location. It also contains the list of IUs and the properties associated with each IUs. Artifacts are the actual content being installed (bytes). Metadata consists of Installable units (IUs) that describes the content that can be installed. Profiles are held by a profile registry which can store many profiles.

I tried to revert to a previous build. Error- Cannot find bundles in repository. Hmm, it appeared that p2 had garbage collected the old bundles in my install and was looking in my defined repositories for the bundles. Ironically, I had recently cleaned up our integration builds repo so that we weren't consuming so much space on the eclipse.org servers. So the bundles I needed to revert to were nowhere to be found.

I didn't really want to roll back to an even earlier build. And I wanted to be able to update to newer integration builds. (My eclipse install dates to March 2009 and I've been updating it since then without an issue). Since I'm the Eclipse project release engineer, my solution was to rerun the missing build locally and recreate those exact same bundles on my local linux server. Reproducible builds are essential. We tag the builder and map files each build so that the builds can be run again and create the same binary bits. I wrote a little shell script to use the versions of the map files and builder that were use to create that build. Ran the build. Added the temporary repo to my install and tried to revert again. I was feeling pretty confident that this would work, or to paraphrase xckd, "Watch out, I know release engineering".

No. Could not revert. It turns out that I had also been using an integration build of Mylyn which had also been cleaned from their repo. So I had to revert to an earlier Eclipse milestone build before I had installed Mylyn, then update to the latest SDK I-build and re-install Mylyn.

In conclusion

You can selectively update part of your install, but cannot selectively revert. Reverting to a profile state is an all or nothing deal.
Regular expressions are better than release engineers.

Further reading

OSGi semantic versioning
Eclipse Version Numbering
p2 tutorial
CRISP builds
p2 garbage collection

Building Open Source: the Backstory

2010-12-03T05:53:00.000-08:00

Last week, I wrote a post that compared the Eclipse and Mozilla build infrastructure. It was surprised by the interest it generated. My conclusion? People like to learn about complex build systems and scalability. Shiny hardware doesn't hurt either. At the same time, I was also thinking about what would make an interesting proposal to submit to EclipseCon.

In the midst of the mundane task of rebooting a performance machine in the lab, I was inspired. Wouldn't it be interesting to open the door into a larger set of open source communities? To explore how they manage their build and release processes, hardware, software and the underlying technologies they use to transform source into binaries?

Image © criggchef, http://www.flickr.com/photos/criggchef/2665328223/ licensed under Creative Commons by-nc-sa 2.0

At Eclipse, sometimes we tend to limit ourselves to examining the projects within the Eclipse ecosystem itself as benchmarks for comparison. Other open source foundations, such as Mozilla, Gnome, Linux and Apache, have similar challenges. Do they have a centralized build farm? How do they support multiple streams, platforms and SCMs? How do they manage hardware and parallelize enormous test suites? What CI engine do they use? Why? How do they optimize their build processes to support their community's goals? I think the open source build backstory would expose some interesting ideas to the Eclipse community.

Image of Toronto Reference Library © Andrew Louis, http://www.flickr.com/photos/hyfen/3562200168/ licensed under Creative Commons by-nc-sa 2.0

You may be thinking, "Kim, you're an Eclipse release engineer. What do you know about builds at other open source foundations?" The beautiful thing about open source is that it is full of passionate people who love to talk about their work. And by virtue of its open nature, we are free to discuss and learn from others. I'm confident that I could create compelling content by talking to other release engineers to tell the story behind their builds.

Image of Thomas Fisher Rare Books Library, Toronto © Andrew Louis, http://www.flickr.com/photos/hyfen/3562167028/ licensed under Creative Commons by-nc-sa 2.0

There are certainly a lot of fantastic talks proposed for EclipseCon this year. If you're interested in this talk, please express your interest on the EclipseCon proposal. Thank you for your consideration!

Mozilla versus Eclipse build infrastructure

2010-11-23T13:33:00.000-08:00

The Mozilla foundation is similar to the Eclipse foundation in many ways. However, it has a wholly owned non-profit subsidiary, mozilla.com, which has a sizeable engineering and marketing staff
that work on the Mozilla projects themselves. The Eclipse foundation's revenue comes from membership dues from member companies. Much of Mozilla's revenue stream arises from search functionally embedded in Firefox that generates cash flow from companies such as Google, Amazon, Yahoo and eBay. Of course, Mozilla projects provide more general desktop tools, than the specialized tools we provide at Eclipse, so they have a larger user base.

A while ago, I watched a webinar regarding the Mozilla build process.

It has some interesting numbers. Today, Mozilla has

12 release engineers
17 platforms to support
12 branches to build from
1200 build and test machines
3 colos

Each of their builds consumes 12.40 hours of build time, 54.48 hours of test time and 2.79 days of CPU time. Because of the enormous resources that the build consumes, they run a lot of tests in parallel. With 1200 machines you can do that :-)

They also run many performance tests with each build. Since the hardware must be identical to compare performance results across machines, 350 of 1200 machines are Mac minis. It's the lowest common denominator for hardware that can run on Mac, Windows and Linux operating systems. In addition, they have a small footprint in a colo, and are relatively inexpensive.

Mozilla's many Mac minis

At Eclipse we have,

15 platforms to support
2 branches to build from (Helios and Indigo)
5 eclipse.org build and test machines

The Eclipse project builds for 15 different platforms but we only run JUnit tests on three. We don't have the hardware to run tests on all of them. Windows, Mac and Linux are represent the vast majority of users and many of the platforms have low download numbers. The SWT team tests all 15 platforms a few times a milestone and ensure that they start up and work as expected.

The build scheduling engine they use at Mozilla is Buildbot, where we use Hudson on eclipse.org servers. Their build process used to take ten days to make a release available. This wasn't really acceptable. Mozilla have what they call "zero day" or "chem-spill releases" where they must prepare a release in a single day to address a critical issue. This is really an admirable feat. During the Callisto release, I recall having to stay up all night to ensure a build completed to ensure a critical fix was available for the release train the next day. I'm not sure that with the size of the Eclipse release train today, a zero day release would be possible if a lower level project had to be rebuilt.

Mozilla also run tests on a number mobile devices. To reduce interference between these devices, they are stored in an IKEA shoe closet in the colo.

It's interesting to see how other open source organizations manage their builds. How do you see the build infrastructure evolving at Eclipse?

Number Nine: Happy Birthday Eclipse!

2010-11-07T11:07:00.000-08:00

This weekend, the time changes in many regions of North America, to allow more sunlight into our darkening days.

Image © Brandon Christopher Warren, http://www.flickr.com/photos/brandoncwarren/4334456172/ licensed under Creative Commons by-nc-sa 2.0

Sunday November 7th, 2010 marks the ninth anniversary of the Eclipse 1.0 release. Happy birthday Eclipse! I'm always amazed at how much we have accomplished as a community.

Image © Rob J Brooks, http://www.flickr.com/photos/robbrooks/3301757153/ licensed under Creative Commons by-nc-sa 2.0

Last year the Apache Software Foundation, celebrated their tenth birthday with cake. That's too low key for us. Rumour has it there will be dancing and democamps this month.

At Eclipse we ship, we don't slip

2010-06-23T13:36:00.000-07:00

Software development is a discipline famous for missing deadlines. Not at eclipse.org.

We ship.

Image © One Hill Tree Studios, http://www.flickr.com/photos/onetreehillstudios/3743874473/ licensed under Creative Commons by-nc-sa 2.0

We don't slip.

Image © Carina Ice http://www.flickr.com/photos/carinaice/4689720312/ licensed under Creative Commons by-nc-sa 2.0

Congratulations to all the Helios participants whose worked so very hard over the past year to make this release a success. For the Eclipse Project, this represents nine years of shipping at the end of June. Helios also represents the fifth coordinated release for the Eclipse foundation. This is an amazing accomplishment! I hope that you can all enjoy some time to relax over the summer months.

Image © Royce Bair http://www.flickr.com/photos/ironrodart/4290027967/ licensed under Creative Commons by-nc-sa 2.0

For those of you who don't need a break, our builds toward 3.6.1 start tomorrow morning :-)

How to explain open source to your family

2010-06-18T08:12:00.000-07:00

I've had the following conversation several times in my life. While meeting a new person at a party, or catching up with a relative that I haven't seen in a while.

Q. So Kim, what do you do for a living?
A. I work at IBM where I spent most of my time working on a open source project called Eclipse.

Q. Open source? Isn't that where they give away software for free? How do you make money off of that?
A. Well, IBM makes products based on this open source software. It's an advantage to have people involved in the open source community and working on improving the software they consume for their products.

Q. So you get paid to give away your work for free?
A. Yes.

Q. What does this open source software do?
A. Well, it's used by other people to write more software.

Awkward pause.

At this point, I often wish that I had lied and told them that I'm a vet. Because everyone loves puppies.

Image by gareso14

Anyways, I saw the most excellent link cross my twitter feed last night from the Open Source Business Resource that explains why we work in open source in a very funny and accessible way.

video: Paul Ramsey explains to his mother in-law why career in #opensource is not as insane as it appears #osgeo http://ht.ly/1ZZFL

The video "Beyond Nerds Bearing Gifts: The Future of the Open Source Economy" has bunnies, evil geniuses and swordplay. It compares open source software with evolutionary biology to illustrate the advantages of a corporation investing in open source. I highly recommend taking the time to watch it. (There's 30 second commercial at the beginning).

Ottawa Helios Celebration

2010-06-16T06:45:00.000-07:00

In celebration of the Helios release, ~~some eclipse committerati and Eclipse foundation staff will be meeting for lunch next Wednesday~~ eclipse family from the Ottawa area are invited to meet for lunch next Wednesday*. Here are the details:

Marshy's Bar and Grill, 117 Centrepointe Drive, noon, Wednesday June 23

Image by claudmey

Food, beer and eclipse family, what could be better? Helios is a tremendous accomplishment, let's celebrate! The software is free, but there isn't free lunch so please bring your wallet :-) Let me know if you plan to attend in the comments, so we can adjust the number of people in the restaurant reservation. See you there!

*I changed the introduction to be more inclusive. Denis told me that it sounded like I was excluding people. That certainly wasn't my intention but I'm a release engineer, not a wordsmith. I always listen to what Denis says :-)

Bundles and Oranges: Dare to Compare

2010-05-28T10:38:00.000-07:00

Equinox p2 provides several tools to manage repositories.

Image by Oliver Delgado

The mirroring task is used extensively in the Eclipse and RT Equinox build. Mirroring a p2 repository allows you to copy the metadata and artifacts to a new location. You can mirror your entire repository or a subset of IUs to a new location. We call mirroring a subset of IUs slicing.

Image by Safari11

The granularity of your slicing operation is dependent on the IUs you specify.

Image by shin0

We run the mirroring task with a comparator. This allows us to compare the bundles that have just been built with the bundles that already exist from other builds in the composite repository. We want to guarantee that the bundles with the same unique identifier and version have the same binary content. Do you know which of or your bundles is not like the other?

Image by Stephanie Berghaeuser

A different compiler with the same source could produce different byte code. Using a new builder can change the content of your bundles, for instance if you enable source references.

We use a comparator with a baseline to compare the bundles with the same name and id available in our repositories with the ones that were just created in the current build. Newer bundles with the same id and version are discarded. This process guarantees that if a user installs a build from a repository or a zip, they will have the same bundles in their install. Otherwise, you risk inconsistent bundles for your users. Not good.

We call the p2.mirror task like this:

We are mirroring from the source (unzipped repository of our build time feature containing all features and plugins in the build) to the child repository location. The IgnoreErrors flag is set to true so the mirroring operation doesn't fail if there are differences. The org.eclipse.equinox.p2.repository.tools.jar.comparator is used to compare the bundles between the two locations and output the differences to a log. The repository location or baseline is the existing composite repository with content from older builds. The comparatorLog is parsed by a JUnit test which generates a failure if the log indicates differences. You can also exclude certain bundles from being compared, as you can see in the exclude stanza.

Other information on p2 repository tools and the comparator
Bug 302283 - add ability to exclude bundles when running comparator with mirror task
Bug 312962 - Exclude doc bundles from comparator
Implementing composite repositories in your build
Slicing and dicing the p2 way
Andrew's comparator slides from EclipseCon 2009

Hey Kim, what's with all the oranges? I'm very fortunate that I have the opportunity to run my first marathon with my friends on a beautiful course in Ottawa and Gatineau this Sunday. It will be a challenge. After the race, there will be sweet orange slices in the recovery area for the 39,000 people running in Ottawa this weekend.

Webmaster kudos

2010-05-18T08:51:00.000-07:00

Sometimes, while working in open source, we don't take time to say thanks. We are so intent on fixing bugs and moving on to the next one.

I'd like to take the opportunity to say thanks to the webmasters for some work they did this weekend that substantially improved CVS performance. From Denis

"We moved the download.eclipse.org and archive.eclipse.org mounts to the other NFS server (the one that serves pserver and other less important stuff), and that seems to have made an enormous difference".

Our build now takes 40-50 minutes less because of this change. This makes our team much more productive. And a faster build makes me a happy release engineer.

Image © psd, http://www.flickr.com/photos/psd/2086641/ licensed under Creative Commons by-nc-sa 2.0

Thank you Matt and Denis for all your hard work improving the eclipse.org infrastructure.

Eclipse Top Ten: #10 You can be the one to make a difference

2010-05-14T13:43:00.000-07:00

Sometimes, I'm disillusioned with democracy. It's messy and difficult. Don't get me wrong, I wouldn't want to live in a dictatorship. But does my vote really matter? I don't know. When I email my Member of Parliament to express my opposition to a bill, do they really value my opinion? Judging by the generic form letter that I receive in return, I am deeply skeptical.

The Eclipse community is small which means that as an individual, you can be the one to initiate change.
At Eclipse, my vote counts.
You bug fixes can help people ship new products, make their work day more productive or even monitor robots on Mars.
That's really amazing.
People appreciate that and it's great to hear positive feedback on your work on an ongoing basis.
You can be the one to make a difference, positive or negative.
You can be the one to find a critical bug before release day
Or after release day.
Nothing is better that working with people who care about what they do. Hands down.
Just look at all the people who have won the Eclipse Community awards this year. They made a difference.
And that's why I like working in the Eclipse open source community.
Thanks to all of you for making this a great experience over the years.

Previous Top Ten posts

1, 2, 3, 4, 5, 6,7, 8,9

The entire presentation is now available on slideshare.

Eclipse Top Ten: Important lessons I've learned working on Eclipse

Eclipse Top Ten: #9 Teamwork

2010-05-14T12:59:00.000-07:00

Image © Alan Chia, http://www.flickr.com/photos/seven13avenue/2768996935/ licensed under Creative Commons by-nc-sa 2.0

Everyone has to care.
If the webmasters didn’t take care of the servers, we wouldn’t be able to release or build software
If the Eclipse.org IP team didn’t do their job we couldn’t use third party libraries or contributed code
If companies didn’t release products based on Eclipse, there wouldn’t be anyone to pay the bills :-)
If the community wasn’t there to open bugs, work through problems or write articles our software wouldn’t be what it is today.
Last, but not least, if the committers weren’t there, getting up each day and caring about the future of Eclipse, we wouldn’t have much progress.
We ship together as a team.

Previous Top Ten posts

1, 2, 3, 4, 5, 6,7, 8

Eclipse Top Ten: #8 The Proof is in the code

2010-04-27T08:43:00.000-07:00

Image © Fábio Pinheiro's http://www.flickr.com/photos/fabio_dsp/150592235 licensed under Creative Commons by-nc-sa 2.0

Before Pascal started his new job at Sonatype, his office was across the hall from mine for several years. I learned many unique expressions from him :-). One them was "the proof is in the code".

Let me expand on this statement.
At its very heart, Eclipse is a meritocracy.
The more you do, the more responsibility you have.
If you want to drive the direction of a project.
You won't get too far by shouting from the sidelines.
The proof is in the code.
And I say code, I don't just mean actual code.
There are many ways to contribute to eclipse.
Write documentation.
Triage bugs.
Respond to newsgroups.
You get the idea.
Don't promise and not deliver.
Going back to transparency theme, everyone will know what you're not doing.
Execution matters.

Here is the original picture I had for this slide. I didn't use it at EclipseCon. Maybe it's not too professional. However, it conveys the idea well.

Here is another picture that I could have used. My friends and I ran the Around the Bay 30K the weekend after EclipseCon as a slow training run. Each kilometer marker had a message.

Previous Top Ten posts

1, 2, 3, 4, 5, 6,7

Eclipse Top Ten #7: Finding common ground goes the distance

2010-04-22T14:34:00.000-07:00

In the eclipse community,
sometimes there’s public humiliation,
and sometimes there’s bribery.
Have you ever bought someone a beer to encourage a bug fix? I think many of us have.
Asked a pointed question on a mailing list to try to shame people into action? Yes.
However, the only real thing that works in the end
and that will get people working together
is common ground.
You both have to care about the same feature or bug fix.
Enough that you are willing to commit your own time and effort to get it implemented.

And the interesting thing is, that once you have a group of people who care about moving forward on the same issue.

What do you get?

Diversity.

Here's a picture of the companies that are contributing to Equinox p2 or are basing products on it today.

The p2 bundles were released into the Eclipse SDK in 3.4M6 (March 2008). We've come a long way.

Public humiliation and bribery can only go so far. Finding common ground goes the distance.

Previous Top Ten posts

1, 2, 3, 4, 5, 6

Eclipse Top Ten #6: Eclipse is like family

2010-04-20T18:15:00.000-07:00

Photo by Anne Jacko

The Eclipse community is sometimes like a large extended family.
You have PDE cousins.
SWT and p2 Aunts.
CDT and WTP Uncles.
It’s good to have a shared history so people understand where you're coming from and the perspective you bring to the table.
To have people to back you up when times are tough.
You can share funny stories.
Gossip.
Families ask tough questions.
In your real family, someone at the dinner table might ask “When are you getting married?”.
In Eclipse, the question will be “When is your project going to become more diverse?”.
Just a note, in the context of Eclipse, diversity always seems to refer to the number of different companies working on a project. In a more traditional office environment, it would refer to the number of women or visible minorities.
Other questions from the Eclipse family might might be:
“When are you going to fix that bug that I opened three years ago?”.
“You know, that company isn’t really pulling it’s weight. They need to step it up and donate more resources”.
Honesty is good. It’s great that we can have candid discussions about the future.
The interactions that I’ve had with the Eclipse community over the years have been overwhelmingly positive.
However, for me, there have been some awkward moments with the Eclipse family.
Here’s a question – what shouldn’t you do with family?
Anyone?
You shouldn’t flirt with family.
No.
In the past, I've received some very friendly emails from random members of the community. People that I don't know.
There are many fine dating sites on the internet. Eclipse.org isn't one of them.

Previous Top Ten posts

1, 2, 3, 4, 5

Where's the source?

2010-04-20T12:39:00.000-07:00

Eclipse.org has many repositories - where does the source reside for the bundles you're interested in?

Photo credit sanja gjenero

In 3.6M7, the PDE team implemented new functionality to allow you to enable including references to the source location in the manifests of your binary bundles. To enable this in your build, you need to invoke your build with bundles from I20100414-1200 or later and add the following

generateSourceReferences=true

to the build.properties of your builder.

During the build process, PDE build generates a file called sourceReferences.properties in same directory as your generated fetch scripts that lists all repository information for the bundles compiled from source. It looks something like this:

#Tue Apr 20 09:23:19 EDT 2010
org.eclipse.help.appserver,0.0.0=scm\:cvs\:pserver\:dev.eclipse.org\:/cvsroot/eclipse\:org.eclipse.help.appserver;tag\=v20090429_1800
org.eclipse.ui.forms,0.0.0=scm\:cvs\:pserver\:dev.eclipse.org\:/cvsroot/eclipse\:org.eclipse.ui.forms;tag\=v20100419
org.eclipse.jdt.debug.ui,0.0.0=scm\:cvs\:pserver\:dev.eclipse.org\:/cvsroot/eclipse\:org.eclipse.jdt.debug.ui;tag\=v20100419
...

The source references are generated from the map files. If you specify extssh connections in your map files, you may want to replace them in the sourceReferences.properties file with pserver connections in the postFetch phase. Only committers use ssh to connect to eclipse.org :-)

The resulting bundles from the build will with have a new Eclipse-SourceReferences header in their manifests. The manifest for the org.eclipse.osgi bundle from today's integration build is an example.

The source references in the manifest can be consumed by PDE when you import a binary bundle into your workspace, so you can easily find the source. When you import your bundles, you can select Import As Projects from a repository.

Select the bundle(s) to import

You'll be prompted if you want to import the version specified in the manifest or from HEAD. Since the bundles we are using are from an integration build and have the version specified, we'll use the v20100419 version.

You'll be prompted for a connection to use and then voila! Version 20100419 of org.eclipse.osgi will appear in your workspace.

This should be useful to people to find the source of the eclipse projects that they would like to contribute to or consume. It would also be interesting to see how this works with other SCMs, all of our source resides in CVS.

Thanks PDE team!

For more information see the following bugs
Support embedding repository information in released bundles
Test generating source references in the build

Eclipse Top Ten #5: Communication is just as important as code

2010-04-16T13:56:00.000-07:00

Comic courtesy xkcd.

Communication.
Sometimes as software developers this isn't a natural skill.
But it’s essential.
Communication is just as important as code.
You can have an incredible eclipse project.
You understand it because you've spent months working on it.
But if no one else understands it. They won’t use it.
Or if they try to, they will blog about how hard it is to use.
Any publicity isn’t really good publicity.
Talk to your community. Get feedback. Get them involved.
Or else someone else will talk for your project.
And you may not like what they have to say.
Help manage your message or someone else will.

Previous Top Ten posts
1, 2, 3, 4

Eclipse Top Ten: #4 Complaints taste better with a side order of contribution

2010-04-15T11:59:00.000-07:00

Photo by Leon Nanda

Sometimes the people have unusual perceptions of what constitutes participating in open source.
Open a feature request.
Done!
Someone else is going to fix my problem!
Nope.
It’s not a viable business plan to expect others to fix the bugs that you care about.
If you want to ensure that your issue gets fixed, get involved in the process.
Ask how you can help.
This gives you credibility in the community.
As a committer, I'm much more likely to look at a bug if the person offers to help.
Once you get your hands dirty with all that delicious open source code, perhaps you'll decide to that you want to do more.
Triage a few bugs.
Verify several fixes.
Write some patches.
You're walking along the path to becoming a ~~cook~~ committer too.

Previous Top Ten posts

1, 2, 3

Architecture Council +2

2010-04-13T13:24:00.000-07:00

I'm honoured to be recently nominated and appointed to the Eclipse Architecture Council. Thank you Chris for nominating me, and thanks to the council for their +1s.

(Image © Chris Campbell, http://www.flickr.com/photos/cgc/162480599/, licensed under Creative Commons by-nc-sa 2.0)

There are many changes happening at Eclipse these days, and it will be interesting to work with my colleagues on the council on these important issues. For instance, the eventual deprecation of one of our SCM systems and migration to a new one requires a robust migration plan from a build standpoint. Once e4 1.0 is released, some projects will start building against it, how will this impact the release train? I'd like to work with the community to strengthen the build infrastructure offered by the Eclipse Foundation. As I have written before, one my goals is to move the Eclipse and Equinox project's build to the Eclipse Foundation in the interest of making it more open and scaleable. I hope that other projects will also be able to leverage this test infrastructure. There are several competing build technologies offered at Eclipse - which will thrive, which will falter? Interesting times.

I also look forward to serving as a mentor to new projects and help them navigate the waters at Eclipse.

(Image © pansapien, http://www.flickr.com/photos/pansapien/231746775/in/photostream/, licensed under Creative Commons by-nc-sa 2.0)

I'd also like to extend congratulations to Kenn Hussey who also recently joined the Eclipse Architecture Council. Small piece of trivia: Kenn and I both graduated from the same university and high school. Nova Scotians - we deliver :-)

Eclipse Top Ten: #3 Ask for directions and help people find their way

2010-04-12T12:21:00.000-07:00

The eclipse.org ecosystem has a huge wealth of talented people with a broad range of experience.
They are willing to help.
They love talking about what they do.
In fact, sometimes it’s hard to get them to stop.
Go out into the hallway after this presentation and I guarantee you'll find someone who won't stop talking about their project.
We are passionate about open source software.
So, if you don’t understand something ask for help.
Bugzilla, forums, mailing lists, Twitter, IRC.
Sometimes I arrive for work in the morning and see a post on planeteclipse from someone who's ranting at an eclipse project. It can be ugly.
If this is a project under the Eclipse or Equinox umbrella, I often look and see if the blogger has opened any bugs or asked questions on newsgroups or mailing lists.
A lot of the time, they haven't.
Don’t get angry, just ask.
We’re listening. We can help.
Once you're armed with knowledge, you can help others find their way.

And you too, can become a mentor.

Previous Top Ten posts
1, 2

Eclipse Top Ten: #2 Say no so others say yes

2010-04-08T10:00:00.000-07:00

When I first starting working on eclipse, I quickly realized that I have to say no a lot. I only have a couple hundred bugs in my bucket. Not many compared to some of my committer friends.

I have a friend. Let's call him Paul. He has about 1300 bugs assigned to him in the Eclipse 3.x stream. He can solve 20-30 bugs a milestone. Each milestone is six weeks. That's excellent fix rate. So thousands of bugs. Can't fix them all. We'll never have a zero bug count.

In the beginning, I would close bugs with something like "Sorry, I'll never have time to fix this". This isn't a way to win new friends in the community. I've learned that the way you say no makes a difference. You need to say no in a way that will make others say yes. How do you do that?

For instance, say I'm spending a lot of time working on a plan item for 3.6M7. I really don't have time to fix a new bug that a member of the community has just opened in my bucket. But, I can be helpful and give them pointers to where the code needs to be changed.

Here's the repository location of the code. Here are the JUnit tests. I can offer to provide guidance, but you need to take ownership of this problem if you want to get it fixed. Taking ownership means transparency. People will be watching you. This community grows by letting others to step up to the plate.

Previous Eclipse Top Ten posts
1

Eclipse Top Ten: #1 Transparency

2010-04-01T04:53:00.000-07:00

I really enjoyed EclipseCon last week. Thanks to the organizers for making it such a great conference, and to the speakers for all their hard work preparing their talks and tutorials. I had to opportunity to present a short talk called Eclipse Top Ten: Important lessons I've learned working on Eclipse. A few people asked me to blog about the content because they didn't have the chance to attend the conference. These ten things aren't in any particular order of importance. Here's part one. Pretend you're in Santa Clara :-)

Good afternoon, and welcome to EclipseCon.
My name is Kim Moir and I'm the release engineer for the Eclipse and Equinox Runtime projects.
This talk is about the top ten things that I’ve learned working in the eclipse community.
Usually I build SDKs, but after over eight years I've also learned a bit about building community.
Release engineer is kind a boring job title.
I prefer to think of it in more glamorous terms.
James Bond has a license to kill.
I'm a committer with a license to build.

Enough about me. Let's talk about the Eclipse community.

Transparency is one the core tenets of open source.
This requires a change in thinking as a software developer.
You’re not writing code that nobody else will read.
With open source, everyone can see what you do.
They can see your triumphs
And they can see your failures.
Break the build four times in a row? Everybody saw that.
Release a bug to the launcher so that Eclipse doesn't start? Everyone sees that too.
On the other hand, if you ship on time every year, year after year, people notice that too.
It’s good to keep us honest.
And the feedback we receive from the community is invaluable.
Brutal sometimes.
But priceless.

Photo credits
Billard balls by Gábor Suhajda
Lego pieces by Dirk Ziegener

Next: Say no so others say yes.

EclipseCon Exercise Thursday: 570K in total

2010-03-25T15:21:00.000-07:00

Thursday morning we had 24 hardy eclipse family members arrive for a run.

Today the other runners decided to award me today's jacket for organizing the running. Thanks!

Special thanks to EclipseSource and the Eclipse foundation for sponsoring this event. It was a lot of fun! I had someone come up to me at the poster session last night and say that they had found a new business partner while running. That's what EclipseCon is all about. Community and conversation.

A special kudos to Olivier Thomann, the JDT Core lead, who ran 5K every day despite not being a runner before attending the conference. Also, thanks to everyone who came out so early in the morning despite some very late nights.

I hope everyone has safe flights home!

Ada Lovelace day at EclipseCon

2010-03-24T14:27:00.000-07:00

March 24 is Ada Lovelace day. This is a day that to celebrate the achievements of women in science and technology. As you are probably aware, the number of women participating in open source communities is very low. From Noise to Signal.

I think it's fitting that I have been able to spend today at EclipseCon with so many of my peers. As I look around the rooms during talks and tutorials, I think I see more women that I've seen at previously. I don't think the Eclipse Foundation has data on attendees by gender, so my observations are purely anecdotal.

Yesterday, I participated in a build panel. When you enter a room to listen to a talk, the conference staff will hand you a card to put in the +1, 0 or -1 bucket to indicate your opinion when you exit. At the entrance of the room for the build panel, I told the conference staff member at the door that I didn't need a card because I was a speaker. She looked at me and said. "Really? You're a speaker? I haven't seen a female speaker all day. Way to go!".

So this Ada Lovelace Day, I'd like to dedicate to the women attending and speaking at EclipseCon. For the women who have attended EclipseCon this year but not been a speaker, I encourage you to consider submitting a talk next year.

With that in mind, I'm going to head off to a talk by Susan McCourt and Steffen Pingel on the new Mylyn discovery ui in p2.

EclipseCon Exercise Wednesday: Still going strong - now at 450K

2010-03-24T11:51:00.000-07:00

We had 28 people show up this morning for EclipseCon Exercise. Considering all the activity last night at the Hyatt bar, this is very impressive.

Today's winner won an Eclipse jacket for the oldest running shirt (we are very flexible with the categories here :-). A shirt from 1997!

Let's keep it up for tomorrow morning and the last day of the conference. Tomorrow's contest category may be the hotly contested "Best Committer or Contributor Calves". May the best calves win.

This morning, I was remarking that it was amazing that so many people continued to show up every morning. One of the other runners said "Maybe people just love to run." I like that.

See you tomorrow morning at 7am!

EclipseCon Exercise Tuesday: 310K and counting

2010-03-23T18:37:00.000-07:00

I expected the crowd to be diminished today since the shirts were distributed yesterday and a lot of people were celebrating late into the night. No. Eclipse community, you delivered. Look at this picture.

About the same number of people as on Monday. Today's prize category was a "Best Running Shoes". Patrick Paulin won with his Vibram Five Fingers.

I'm so happy that people continue to get up and running for EclipseCon exercise.

Tomorrow's theme is "Best Running Shirt". Wear an old shirt, or a new shirt recently acquired at the conference for the chance to win an Eclipse jacket courtesy of the foundation.

If you're wondering where the 310K came from, it's the approximate number of people who attended multiplied by 5K a person.

See you tomorrow morning at 7am in the Hyatt lobby!

Eclipse Run Time was a Fun Time

2010-03-22T19:48:00.000-07:00

We had 30+ people turn out for EclipseCon exercise this morning. This is a new EclipseCon Exercise attendance record! Way to go!

EclipseSource generously provided technical t-shirts. Since so many people showed up, they all were distributed the first day.

Today's contest category for an Eclipse jacket was "Runner from farthest away". The winning runner was from India. Congratulations! Thanks to the Eclipse Foundation for supporting this event.

We went for between a 5-6K run on the bike trail behind the conference centre. There were lots of different pace groups. Some first time runners. Great job everyone! If you had a hard time with the run, remember that pace makes a huge difference. So slow it down a bit if you didn't feel good when you got back to the conference centre. It's just a fun run not a race. No need to feel nauseous before breakfast :-)

When we returned to the Hyatt, the staff had water bottles and towels for everyone.

Thanks to those who had run this route last year and led the way. I look forward to seeing you tomorrow morning.

EclipseCon Build Panel: It's not rocket science, it's release engineering

2010-03-19T11:42:00.000-07:00

There will be a build panel next Tuesday afternoon at EclipseCon. I'll be one of the panellists and hope that it will be a constructive discussion. Have a question about release engineering but were afraid to ask? This is your chance!

Photo credit clix at www.sxc.hu

We have gifts from our new friends at the Hudson project to give away at the build panel. Hudson is an open source project for a continuous integration server that's in widespread use, including on build.eclipse.org. Like eclipse, it has a plugin architecture that allows you to add functionality incrementally and the community contributes plugins to make Hudson better. The first thirty people who ask the build panel a question will receive a Hudson sticker to affix to their laptop.

The Hudson committers are also having a hackathon this weekend, if you happen to be in the Santa Clara area this Friday and Saturday.

Ten things I wish I'd known as young committer

2010-03-18T13:20:00.000-07:00

On Monday afternoon, I'm giving a short talk at EclipseCon entitled Eclipse Top Ten. My presentation will discuss the important lessons I've learned while interacting with the Eclipse community. Release engineers build SDKs but along the way I've learned about building community as well.

I prepared the slides with the help of the excellent book Presentation Zen that that my Eclipse colleague Lars Vogel recommended. One of the suggestions in the book is to present interesting pictures with as little text as possible. This is to encourage the audience to listen and interact with the speaker, instead of spending time reading text heavy slides.

Photo credit Gábor Shajda http://www.sxc.hu/photo/21223

If you look closely, you will notice the billiard balls are scratched, and a bit worse for wear. I think that's fitting, because as a long time Eclipse committers, some of us are in a similar condition. The steady stream of bugzillas that has rained down upon us for years does leave some scar tissue:-)

For the draft of this talk, I wrote down a list of 50 different things I've learned working in our open source community. I had to do a lot work to condense it down to ten. Given the material I had, I could have had a completely different talk. The end result is a candid and humourous look at the Eclipse community, and how you can get involved to make it better.

What have you learned from open source? The talk is from my perspective, but I'm sure others have much to contribute to this discussion. I look forward to speaking with you at EclipseCon.

EclipseCon Exercise: Vote for prize categories

2010-03-18T06:17:00.000-07:00

There will be Eclipse swag available at EclipseCon exercise. Vote now on the criteria to win. You can vote for four difference categories, one for each day.

Next week is EclipseCon. Interesting talks. New technology. Awards. Surprises. Lego. Robots. Chats with old friends and making new ones. What's the perfect start to such a great day? Running. Here are the steps to ensure your bun(dle)s are running at EclipseCon.

1) Sign up on the EclipseCon exercise wiki so we know you're coming. So far there are 30+ people signed up - fantastic - looking forward to seeing you there!

2) Pack your sneakers, running shoes or trainers. Whatever you call them, make sure they end up in your suitcase. Shorts and a shirt too. As Chris mentioned, there will be EclipseCon exercise shirts for the first 30 runners.

3) Get out of bed for and meet in the Hyatt Lobby at 7am.

The last one is really key. Many of my running friends say "Getting out of bed is the hardest part of running". There's some truth to that. The good news is that it's California. Sunny and warm. Palm trees. Look at this forecast.

Looking forward to seeing you at EclipseCon Exercise!

Confessions for the EclipseCon Speaker

2010-03-17T06:27:00.000-07:00

I recently read a very funny and informative book about the pitfalls to avoid while speaking in public. Confessions of a Public Speaker by Scott Berkun. If you need a great book to read on the plane to EclipseCon, I highly recommend it.

Some of the most important points in the book

Practice, practice practice your talk. This allows you to optimize the organization of your talk and smooth out your delivery.
If you are speaking to a small number of people in a large room, try to convince them to move to the front of the room. People who are sitting together will change the dynamic of the talk. Speaking to a group of people who are scattered around a large room is not optimal.
Go over the agenda in your introduction. For instance, say "I'm going to talk about five points at three minutes a pop. The final five minutes will be for you to ask questions". This will give people an idea of what to expect.
Interact with your audience. Ask trivia questions, for a show of hands or ask the audience to solve a problem.
I notice that a lot of people are working during talks instead of listening to the talk. My employer paid money to send me to a conference and I'm investing my time. So I make a point listen instead of doing my regular job even though it will be painful to catch up with work later on. In the book, he suggests asking people to close their laptops and if they are bored after five minutes, go back to surfing the web. Again, the audience it gets the audience engaged in your talk and your show that your care about your audience. Of course, if they are blogging or tweeting about how interesting your talk is, they can keep the laptop open :-)

The final chapter of the book describes some of the worst things that have happened while people giving a presentation. There's fire, water, and SWAT teams. Hilarious. I don't give that many presentations in my day to day job of building bundles, so I found this book was a great resource . With that note, I must get back to writing slides, practicing my talks, and fixing bugs.

Better builds with Hudson, hardware and help

2010-03-15T08:52:00.000-07:00

Some might say that the build is one of the engines drive a project. The Eclipse and Equinox build needs a tune up.

(Image © Paul Gorbould, http://www.flickr.com/photos/gorbould/3531940727/in/set-72157607916475025/, licensed under Creative Commons by-nc-sa 2.0)

A simplified summary of our build process today is as follows. (Many of these processes occur in parallel.)

Checkout code from eclipse.org to an IBM build server.
Generate build scripts, compile code and create a master feature of all the bundles used in the build.
Copy master feature to eclipse.org for signing, copy back to IBM server when complete.
Run the p2 director to provision products and use repository tooling to slice out zipped repositories.
Run JUnit and performance tests.

Here are some of the fundamental ways this process can be improved:

Hudson

Problem: The build process takes too long to complete code checkout, compilation, signing and packaging. It's also also too monolithic.

Solution: Take advantage of the local access to the eclipse.org filesystem by running the build on the Hudson install at at the foundation. Now that we have hardware donations there will be new Hudson slaves for more build cycles. Also, breaking the build up into smaller builds and chaining them together will let us identify problems earlier. See bug 302436 for details. We run test builds on Hudson today and they work very well.

Hardware

Problem: There aren't enough test machines to run our tests in a reasonable timeframe. Committers aren't able to rerun the tests on the same hardware that was used in the build.

Solution: New test hardware at the Eclipse foundation is a start. We'll probably need more but it's a good beginning. Thank you to all the companies who have donated hardware to the foundation recently.

Help

Problem

Today we run our JUnit tests on Windows machines by invoking them via rsh. This allows us to manipulate the display while running ui tests.

Solution

This is where you come in.

I'm not sure how to do this on Hudson. Sonatype has a series of articles on running tests in a multiple OS environment and they state that this is still a problem for them. If anyone has any pointers to articles on how to do this it would be appreciated. Please update bug 305213 with your suggestions.

Also, we need some rack mounted Macs to run JUnit tests on this important platform. So once we get the new hardware integrated, some more hardware donations would be welcome :-)

AFOL at EclipseCon

2010-03-08T08:04:00.000-08:00

I read an interesting book over the weekend. Groundswell is a book from the Harvard Business Press written by Charlene Li and Josh Bernoff. It discusses how to use social media to open up communication channels with your customers. For instance, how to harness the wisdom of the crowds to design better products and improve technical support. The book describes the approaches of several companies and shows the ROI calculations for the investment in social media.

One of the companies that was profiled was the Lego Group. I learned that Lego is the sixth largest toy manufacturer in the world. Over a billion dollar a year business. And somewhere between 5-10% of their sales go to AFOLs. Adult fans of Lego. In fact, they have an executive in charge of marketing to AFOLs because it is such a significant market. AFOLs hang out in an online community called LUGNET. The Lego Group's approach to social media is to have Lego Ambassadors in the AFOL community listen to the needs of the people who view Lego as a building material, not just a toy. And these amabasadors are paid for their services in Lego bricks, not money. Pretty cool.

So what does this have to do with Eclipse? EclipseCon 2010 is having a e4-Rover Mars challenge where you have the chance to use Eclipse technology to maneuver Lego robots. Go to EclipseCon and add four letters to the end of your name without paying for tuition. AFOL at EclipseCon!

Community starts with conversation

2010-03-05T13:46:00.000-08:00

This week, I've been writing slides for our p2 tutorial at EclipseCon. As part of this effort, I wanted to show the companies that were shipping products based on p2 or that used p2 in their internal products. I asked for suggestions on the p2-dev list. Here's a summary of the responses.

Pretty interesting. It's a testament to the Equinox team and the larger community that so many companies are building products based on p2. If your company, belongs on the slide, let me know.

Pascal has arranged a p2 BOF at EclipseCON. It should make for interesting conversation.

Tag after Release

2010-03-02T11:18:00.000-08:00

Last week Eclipse and Equinox 3.5.2 was released as part of the Galileo SR2 release. So far, so good! A big thanks goes out to David Williams for keeping all the projects on the release train in line and ready for SR2. Also, kudos to the webmasters for ensuring that the mirrors were ready for the release.

The work of the release engineer isn't done after the release bits are available. I tag all the projects in the Eclipse and Equinox project with as R3_5_2, as well as our our map files and the builder projects. This ensures that if required, exactly the same build can be reproduced. In addition, it's useful for developers to be able to compare against a tag for a previous release, or to branch from a tag.

Our source resides in the /cvsroot/eclipse and /cvsroot/rt repositories. The steps I take to do this are as follows:

1. Start eclipse with a clean workspace.
2. Check out the vM2010211-1343 versions of org.eclipse.releng and the builder projects. Every time we run a build, the org.eclipse.releng and builder projects are retagged with with the build id. M2010211-1343 is the build id of the final 3.5.2 build so I retag these projects as R3_5_2.

3. I remove the orbit map from the releng project in my workspace. There are prebuilt bundles fetched from the Orbit repository so we don't need to tag them.
4. Replace :pserver:anonymous with :extssh:kmoir in the remaining map files in my workspace. I have commit rights on all the eclipse and equinox projects for this very purpose.
5. Change the connection timeout on the Team CVS client to one larger than the default. Otherwise, your CVS connection will timeout while tagging all the projects.
6. Select the map files in my workspace. Right click and select Team and the Tag Map File Projects option.

7.Tag as R3_5_2.

8. Once all the tagging has completed after several hours, I will check out all the projects from the map files and compare with R3_5_2 to ensure that there aren't any files missing the tag.
9. Install the releng tools to use the "Tag map file projects" functionality. This allows me to tag the versions of projects defined in your map files as another version without checking them out. Very useful.

Questions?

Q.Why don't you do this tagging as part of the build process?
A.Eclipse and Equinox is a large project with a lot of source - over 300 bundles and more than 30 features. Tagging this as part of the the build each time takes a few hours and is often has CVS timeouts. We don't need that, the build is slow enough as it is today :-) That being said, if you have a smaller project of just a few bundles, tagging the bundles with the build id could be useful.

Private Emails Hide the Details

2010-02-16T11:02:00.000-08:00

Recently, I've been receiving a lot of emails directly to my IBM address regarding bugs, features, releng questions, or building Eclipse for platform XYZ from people in the community. These people are new to Eclipse and therefore may be unaware of the proper channels to ask questions. I like to gently remind people ask a question on the forums or open a bug. The internet is forever, and Eclipse is no exception. If you open a bug, others with the same issue will be able to search and find a solution. Private emails hide knowledge that's useful to the larger community. As committers, we're very detailed oriented people.

Today, I responded to the latest request as follows:

At eclipse,
We're open source,
Private emails,
hide the details,

Asking in the open
Allows others to see,
the issue described,
the remedy prescribed,
for posterity

Found a problem?
Want to request a feature?
Please, I will ask,
open a bug for the task
https://bugs.eclipse.org/bugs

I look forward to seeing their bug.

Trim your builds with p2 repository tools

2010-02-11T12:48:00.000-08:00

The Eclipse Project has the unusual distinction of consuming the most download space of any project at eclipse.org. Therefore, I like bugs with a request to "get rid of stuff" versus "add more stuff". Recently, I fixed a bug to remove the packed jars from our zipped repositories that are available for download.

For example, we provide RCP binary and RCP source zipped repositories on our download page. Last week, these zips included both packed (*.jar.pack.gz) and unpacked (*.jar) bundles.

We don't need to include both types of jars in these downloads because most people will install the bundles locally from the zip.   The packed jars are included by default because when I run the mirror tool against the full build repository to create the slice, it already includes the packed jars. You can use the remove.iu tool to query the repository for a list of all bundles and remove the associated packed jars.

<p2.remove.iu>
        <repository location="file://${yourRepo}">
        <iu artifacts="(format=packed)" query="">
</iu>

The remove.iu tool will remove the packed bundles from the repository and update the artifacts.jar accordingly.

As I have written before, repository tools are very useful for creating subcomponents of existing respositories.

Remove IU

Slicing and Dicing the p2 way

Want to learn more about using p2 to assemble products out of pre-existing components? Plan on attending the From build to assembly to deployment: Using p2 to facilitate agile software development tutorial that Ian Bull and I will be presenting at EclipseCon.

Committer Collector Cards

2010-01-28T12:02:00.000-08:00

I have a new idea for Eclipse swag. Committer collector cards. Why? It would be a fun way to get to know more about members of the Eclipse community. Like hockey cards. But we're better at debugging, and have more teeth.

Here are some ideas for the sorts of information that this could display.

Name
Picture
Commit rights
ohloh commit history
LinkedIn url
Special power

Special power? Yes, all committers have special powers. As a release engineer, my special power is pain tolerance. Much like Wolverine. Yes, it's true.

I can see this being a popular activity at EclipseCon. Trade a Moir for a Merks, a Bokowski for a Bull. What do you win if you collect a whole project? Bugzilla bingo. You get a bug assigned to you so you can earn your own commit rights. Diversify the community. It's all very win-win.

Since I'm in the give away free software business, not the marketing swag business, I thought I'd suggest this idea for any enterprising people out there. It could be a branding activity a company who'd like to sponsor such a unique piece of swag. Go for it!

EclipseCon Exercise: Commit to Running

2010-01-22T12:36:00.000-08:00

EclipseCon 2010 looks like it will have a fantastic program this year with many interesting talks. For instance, there will be talk about Lego Mindstorms and Eclipse. How much do I love Lego? Let me show you my keychain.

There will be also be a talk on the Eclipse at NASA which looks really interesting. I mean, how often is it that the software you build is used to monitor robots travelling across another planet? Mr. Platform Releng is very talented at ordering stuff on the internet. One day I arrived home and found a Lego Mars Rover being assembled in our living room. Life is unpredictable. From l ego.com.

Outside the formal program, there will be EclipseCon Exercise early in the morning. You're invited to sign up for a run every morning before the talks begin on the wiki. Don't hesitate to put your name down if you've just started running, there will be several pace groups. Thanks to the work of Darin Swanson, who organized EclipseCon Exercise in previous years, we already have a map.

The generous Eclipse Foundation has also agreed to provide prizes for the EclipseCon Exercise participants. There will be Eclipse shirts and running related gifts. What will you win a prize for? Well, that's up to you. Again, you can make suggestions on the wiki for prize categories and I'll set up a vote for the community in early March. Also, if you work at a company that's interested in sponsoring EclipseCon exercise, please contact Donald Smith.

Running before the talks in the morning is a great way to clear your mind for the day. It's also a way to get rid the jitters before you give a talk or tutorial. Most importantly, it gives you a chance to meet and talk to people in a different context, and get to know them better as a person, not just an Eclipse professional. Learn about what they do outside of work, their communities, and discover common interests.

So consider committing to EclipseCon Exercise. Sign up today and remember to pack your running shoes!

Sign up sheet for EclipseCon Exercise 2010

p2 tutorial RFC

2010-01-12T08:25:00.000-08:00

The EclipseCon program committee is sending out acceptance notifications after completing the difficult task of selecting the talks that will be presented in March. Thanks for all your hard work - I'm sure it will be an amazing conference!

Ian and I have been selected to give a tutorial entitled "Exploring p2". The best approach to learning is spend time actually getting your hands dirty. The wisdom of xkcd

Originally, the focus of this tutorial was to be on building with p2. However, given time constraints in the build category, the program committee asked us to provide a broader focus on p2, not just building with it.

This is where you come in. If you are considering attending this tutorial, let us know what topics you'd like us to cover on the wiki or leave a comment. We really value your input and so we can tailor the tutorial to you. Also, it will be interesting to learn the p2 use cases in the community. A tutorial is a two way street, and we have just as much opportunity to learn about how you are using the software we build, as we have the chance to share our experiences with you.

Keep in mind that there are other talks in this topic that have been approved. For instance, Pascal will be conducting a talk on p2 APIs. Today, our fantastic Equinox committers are working on merging the newly minted p2 APIs into HEAD for 3.6M5.

Looking forward to seeing you at EclipseCon 2010!

Less email, more info

2010-01-07T13:01:00.000-08:00

I subscribe to many eclipse mailing lists. This means I get a lot of email that's sorted by various filters so my inbox doesn't explode with all the traffic.

However, there are some Eclipse projects that I'm interested in, but not going to participate actively on the mailing list. This reminds me of the pig and chicken analogy. I'm somewhat involved in the other projects, but I'm committed to others. From implementing Scrum

Luckily, each eclipse.org mailing list also has a RSS feed.

For instance, this time of the year, it's interesting to watch the EclipseCon Program Committee feed. Lots of discussions regarding which talks will get the final +1 for the 2010 program.

Or you may have an interest in what's happening in e4, but don't want all the email that this very active project generates.

And the winner is.....

2009-12-14T13:15:00.000-08:00

Eric Rizzo has won the December splash screen contest with this submission.

Congratulations! Thanks to all the contestants for submitting such creative artwork. The winning design will start appearing in tonight's build (N20091214-2000) and has been tagged for the integration build.

Vote now for your December Splash

2009-12-11T10:49:00.001-08:00

Next week, we'll have the our final integration build before the end of 2009. What better way to end the year than with a custom splash screen? As usual, the very creative Eclipse community has stood up to the challenge with eight different designs for your consideration. Please vote here:

Direct link to poll.

The poll closes on Monday at 5 pm EST. I'll announce the winner on Monday and commit the winning splash. Good luck to all the contest entrants!

This contest is closing a bit earlier than expected because we shutdown our builds over the holiday season. Thus, we need to get the December splash into the integration build on December 15, 2009.

Eclipse and Equinox 3.6M4 now available

2009-12-11T06:55:00.000-08:00

Ho ho ho.
Ho ho ho.
We are Eclipse's elves.

We are Eclipse's elves,
Filling mirrors with M4,
Another milestone out the door.

Oh, we are Eclipse's elves,
We work hard all day,
Debug and refactor is our play,
Bugs we stamp out,
Hurray, the community shouts!

We are Eclipse's elves,
We ship on time each year,
We don't like to brag,
Just sync, commit and tag,
Install new bundles without lag.

We all know who's been good,
Resolved the bugs you should,
Eclipse is you,
Grab a bug and become a committer too!

We are Eclipse's elves.
Ho ho ho. Ho ho ho.
We fix the code ourselves.
Ho Ho!

The Eclipse and Equinox team are happy to announce the release of the Eclipse 3.6M4 milestone.

New and noteworthy

Update to 3.6M4 by adding this site to your list of available sites
http://download.eclipse.org/eclipse/updates/3.6milestones

Equinox Downloads

Eclipse Downloads

Happy Holidays and New Year from the Eclipse and Equinox projects!

December splash screen contest: Prizes++

2009-12-09T06:07:00.000-08:00

Last week, I announced the December splash screen contest. Since then, we've had some entries from Olivier Thomann. Very creative. Look at this

Or this.

We need more people to submit splash screens to to the contest. Here's the bug where you can submit your entry. It doesn't have to be a holiday theme, it can be whatever you'd like.

As an added bonus, the generous folks at the Eclipse foundation (hi Ian and Lynn) have offered to donate some eclipse bling to the prize pot. So the total prize package for the December splash screen contest will be

1. Friends of Eclipse membership
2. Eclipse t-shirt
3. $50 donation to Eclipse in your name

An Eclipse t-shirt? Does it give you special powers like the famous "three wolves t-shirt"?

I guess you'll have to enter the contest to find out. Fire up your favourite graphics editor and submit a splash screen to bug 296918

A tale of CVS, NFS and Swordplay

2009-12-04T09:06:00.001-08:00

Earlier this year, the time that it took our builds to check out code from CVS had slowed to a crawl. Last year, our integration builds that started by 8am were available by noon. However, during the 3.6 cycle, most builds weren't ready until 2pm or even 4pm. Very painful, especially for our European committer friends. Not only were the builds slow, but it took a long time for us to commit code, and timeouts were frequent.

Denis and his merry band of webmasters determined that the source of the problem was twofold.

1) NFS configuration issues causing high CPU load on the servers. (Bug 288293)
2) Anonymous pserver users were holding the cvs lock files for a long time (Bug 293355)

Earlier this week, Denis fixed the NFS configuration issues. This had reduced the time it takes to check out our code significantly. Also, I haven't seen any CVS timeouts lately. Today, our 8am integration build was ready at noon. A big thank you to the webmasters! We are much more productive thanks to your work. Less swordplay while waiting for builds, and more time to fix bugs and implement new features. Again from xkcd.

Really, who doesn't love xkcd? It's so good.

Denis will change the anonymous pserver access to a mirrored copy of the CVS repository on December 11. He sent notes to the committers list with the details. The means that committers won't have to contend with anonymous users for cvs lock files if they check out code via ssh. Psever will be available on a separate file system, but sychronized with the live copy.

In preparation for this change, I modified our build scripts to check out our code using ssh, instead of anonymous pserver. However, our map files remain untouched so anyone can check out our code via pserver. The build scripts modify the map files after they have been checked out. We won't have to deal with file contention for CVS lock files. And ssh connections to eclipse.org have a higher QoS than pserver. Good stuff.

Most teams won't have to make any changes because they run their builds on build.eclipse.org. These users will still pull from the live copy of the data via pserver. And the mirrored copy will be up to date. I'm just trying to do everything I can to avoid infrastructure issues that cause build failures.

See bug 294900 for the platform releng changes.

Make a splash in December

2009-12-04T06:35:00.000-08:00

The Movember splash was a lot of fun. I'd like to open up submissions for a December splash screen. It will be released after M4. This contest is open from December 4-15. At that time, I'll start a poll and ask the community to vote on the splash screen. I'll commit the winning submission. What will you win? Eyeballs on your art. Respect of the community. Warm and fuzzy feelings. And I'll donate $50 to friends of Eclipse in your name.

The existing splash screen is in org.eclipse.platform in /cvsroot/eclipse. The file is splash.bmp. The photoshop files are in 3_6SplashHeliosPsd.zip in the same project. Attach your entries to bug 296918

Nothing offensive please people. Go for it.

Good Eclipse Swag

2009-11-30T13:55:00.000-08:00

I found this mug in the kitchen at work today. It has Eclipse key bindings on front

and back.

Now, all I need is a sandwich to go with this and I'd be set. From xkcd

Swag is rarely both useful and aesthetically appealing. This is both! Thanks itemis!

The end of a three year relationship: Goodbye bug 153429

2009-11-27T12:18:00.001-08:00

This past week, the Eclipse and Equinox team released changes to support the use the JUnit 4 bundle in the Eclipse Test framework in bug 153429. This bug had over 75 people on the cc list and 40 votes to fix it. It was in my bucket for three years. It's finally fixed so now we and (you) can run your automated tests on JUnit 4.

The changes that we made to fix this bug are described in the wiki. John also sent a message to the cross project list.

I have worked on many bugs during my tenure at Eclipse. This was a tough one. It was very complex, and required a tremendous amount of testing. It was also very much a team effort.

I'd like to especially thank DJ Houghton for all his patches for the test harness and and test bundles. Also, DJ added the org.junit 4.7.0 bundle to Orbit which was very helpful. John Arthorne for fixing the p2 tests and all the good advice during this process. Dani Megert and Markus Keller for their changes to JDT. Darin Wright for his advice regarding PDE. Curtis Windatt for his changes to the pde ui tests. Andrew Niefer for the changes to the pde build tests. Other committers made minor changes to their test bundles to accommodate this change. Thank you!

Goodbye bug 153429. I won't miss you.

Committer Reps, we need your help

2009-11-25T12:00:00.001-08:00

Hi Boris, Chris, Doug and Ed

Hey, how's it going. I hope that you are all well.

Like a mall on Black Friday, around here it's peak Eclipse committing season. Lots of bugs to fix. Lots of builds to run. As you know, builds are quite a pain point at Eclipse. I'm excited about the possibilities in the b3 project to make things better. Building software is complex, and Eclipse is no exception. In additional to tooling to make builds easier, we need hardware to make builds faster. Our build today takes about five hours to complete, and an additional 6.5 hours for the tests to complete. Really, it's not pretty.

Many eclipse projects run their builds on Hudson on build.eclipse.org. Hudson is fantastic because there's a rich set of plugins that you can use to enhance the functionality of your build. Also, since this server has local access to the eclipse.org filesystem for code checkouts, you're less prone to network errors which can break the build. It also has ldap integration with your commiter login so you can restrict your build configuration to the commiters on your project. In theory, if you need more build machines to run your build - you can use the Amazon EC2 plugin to provision more machines in the cloud, or other plugins to start builds on local slave machines. Good stuff.

However, one of the things that the foundation doesn't provide today is test machines. This means that we can't run our build at the Eclipse foundation. The Eclipse Project builds zips for 14 different platforms. We run JUnit tests on three native platforms: Windows, Linux and Mac. They are the most commonly downloaded platforms. We need test machines to ensure that we don't have any bugs specific to a platform. Why do our tests take so long? We have 54,000 JUnit tests. You don't produce quality software by skimping on tests.

This isn't just about the Eclipse and Equinox projects. This could be very useful for other projects, for instance, the XSL tools project has expressed interest in using test servers. In addition, these machines could be used as slaves machines for running the build in the event that the main Hudson server is too busy. If we had enough machines, we could run more tests in parallel and reduce the time it takes our build to complete. This would be a big win for the community and our committers.

One thing I investigated in running tests in the cloud. However, most cloud services don't have provide a way to run tests on Macs and we need to make sure that our Mac users are happy. If there is a way, I'd appreciate a link. In addition, one of the advantages of running tests on machines local to the eclipse.org filesystem is that we don't spend time copying stuff back and forth across the network. It's just there.

So, what I'm asking from you is at the next board meeting, please bring up the issue of funding test infrastructure at the Eclipse foundation. It might be even be an advertising opportunity for one of the member companies if they donated hardware. Other companies could donate money to pay for the additional rack space. I don't know right now what the final technical solution will be or what it will cost. All I'm asking right now is to start the conversation.

For many years, the Eclipse project has been criticized for not being open enough. Having our build process fully on eclipse.org servers would make us more open. It would also allow any of the Eclipse and Equinox project committers, regardless of company affiliation, to initiate a build. It we had enough hardware, our build could be faster and we could spend less time waiting for builds, and more time fixing bugs the builds reveal.

Please bring this issue up and the next board meeting.

sincerely,
Kim

P.S. Right now we have the following test machines and our tests take about 6-8 hours to complete. Obviously, if we had more machines running tests in parallel, the build would take less time.
1) JUnit: 2 linux, 2 windows, 1 mac, 1 test cvs server,
2) Performance: 2 windows, 2 linux, 1 database server

Happy Birthday Eclipse...now some pictures from your youth

2009-11-03T12:40:00.001-08:00

Saturday November 7th, 2009 is Eclipse's 8th birthday. Eight years ago the first Eclipse downloads were publicly available along with the source code.

Here's a picture of the first www.eclipse.org. The website was slashdotted shortly after the "Eclipse is open source" announcement was made. The hard drive had to be replaced, thus the missing cover. This machine was replaced by a real server a few weeks later. A couple of years later, this was replaced by faster and more fault tolerant hardware managed by our most excellent webmasters.

I went through my desk the other day, and found some emails of the original requirements for the eclipse infrastructure, project structure and commit rights. A fast server has 512MB RAM and 20GB of disk space...really? Okay, I feel old.

Bugzilla was there from the start.

Some of the first mailing lists. A few disappeared but even more new ones were created. Today, we have eclipse on twitter, forums, conferences, marketplace, blogs and the list goes on. Pretty impressive!

In 2001, the linux kernel still fit on a floppy disk. It was useful to have a boot disk in the event that the boot partition became corrupted and the machine wouldn't boot. Much easier than booting from a rescue cd and mounting all the partitions by hand. Especially at 4am. Here's a picture for those who've never worked with a diskette (*ahem* co-ops :).

Initial project structure. Today we have so much much more.

The first commit rights - hello PDE family! Today we have an amazing diversity of committers from around the world and many companies. Eclipse also has friends, but would always like more....who doesn't?

In reality, the past doesn't matter that much, and we need to focus on the future. Sometimes I'm cynical about Eclipse, because as a long time committer, I notice that many people like to play (consume), but fewer want to pay (contribute). And to some degree we make it difficult to contribute without a significant investment of time and a steep learning curve. But most days, I'm absolutely amazed by the work that we as a community can do together, when smart, passionate people strive toward a common goal. Happy Birthday Eclipse!

Now I see IU, now IU don't

2009-11-03T10:31:00.000-08:00

Eclipse 3.6M3 went out the door over the weekend, along with a lot of Halloween candy.

Sometimes, you can have too much Halloween candy. And sometimes, you can have too many IUs in your p2 repo. Don't believe me - just look at this repo with bogus bundles - scary!

Both scenarios can cause your friendly neighbourhood release engineer pain. This is unusual because we're a very pain tolerant people. To alleviate the suffering, the p2 team added an Ant task in 3.6M3 that allows you to remove bundles from your repo. As much as I love spending quality time at the command line modifying metadata, Ant tasks that automate tedious jobs are even better.

The p2.remove.iu task will remove both the metadata and the bundle from the repository for a specified IU. For example, if you had bogus packed com.ibm.icu.* bundles in your repo, this task would remove them.

<p2.remove.iu>
<repository location="file://${reposource}" />
<iu id="com.ibm.icu" artifacts="(format=packed)" />
<iu id="com.ibm.icu.base" artifacts="(format=packed)" />
<iu id="com.ibm.icu.source" artifacts="(format=packed)" />
<iu id="com.ibm.icu.base.source" artifacts="(format=packed)" />
</p2.remove.iu>

This task is useful if you'd like to remove some built time bundles from your repo. Or just correct a mistake after a release. It happens. In any case, it's all good. Almost as tasty as chocolate.

Related bugs

Support excluding bundles when running p2.process.artifacts task
p2.remove.iu task should have an option to specify to remove packed file only
ICU jars at Eclipse 3.5 update site have size of 0

Hudson is sweet, now the build can tweet

2009-10-21T11:25:00.000-07:00

I recently set up a new Hudson build so the Equinox team could test their changes in a branch instead of releasing everything to HEAD. Hudson, like Eclipse, has a rich variety of plugins that can expand the functionality of your build. Hudson has a twitter plugin and thus Eclipse (test) builds tweet here

http://twitter.com/eclipsebuilds

Right now, there are only a few messages about the test builds I started, and stopped when I saw that build was proceeding as normal. In any case, it's pretty cool.

Hudson also has plugins to use additional slave machines on the network to run the build on a faster machine if the current build machine is too busy. It also has plugins to provision Amazon EC2 images and run the build on a slave in the cloud. We currently run about 54,000 JUnit test per platform multipled by five test machines during each build. We run tests on Windows, Mac and Linux machines. But the tests take a long time to complete simply because of the number of tests we run and the lack of additional hardware to run more tests in parallel. It would be fantastic to be able to run the tests on parallel on many machines and finish in fraction of the time they take today. That would allow us to reduce the number of breaking build issues. But of course, this will take significant testing to implement. Sounds like fun!

References
Run JUnit tests in parallel
Hudson build for the p2 branch

Test bundles switch from runnable to repo

2009-10-20T12:31:00.000-07:00

Earlier this week, I changed the build so that the test bundles are provided in a zipped p2 repository format. A p2 repository looks something like this

...
artifacts.jar
content.jar
features/org.eclipse.sdk.tests_3.6.0.N20091019-1735-9J9fG6sFIKSg8a7j2ZwWY0UAV4BV.jar
plugins/org.eclipse.ua.tests_3.3.300.N20091019-1735.jar
plugins/org.eclipse.jdt.debug.tests_3.1.100.N20091019-1735.jar
binary/
...

The build will install the appropriate test bundles in the eclipse install being tested using the p2 director. Previously, our test bundles were assembled in the runnable format like this

...
eclipse/plugins/org.eclipse.jdt.debug.tests_3.1.100.N20091019-1735/...
eclipse/plugins/org.eclipse.ua.tests_3.3.300.N20091019-1735/..
eclipse/features/org.eclipse.sdk.tests_3.6.0.N20091019-1735-9J9fG6sFIKSg8a7j2ZwWY0UAV4BV
...

and unzipped into the dropins folder. However, the dropins folder is really for legacy purposes. Disadvantages of using the dropins folder include

It's to help those applications that expect that dropping a bunch of bundles into an install will work (!).
All the bundles in the dropins folder are treated as optional bundles.
You can't update the bundles in the dropins folder by using the UI, you are responsible for provisioning them.

The content of the org.eclipse.test framework bundle hasn't changed. However, if you're rerunning the Eclipse and Equinox projects' tests JUnit tests against your product, you'll need to install them into the eclipse your are testing using the p2 director. Unzipping the our JUnit bundles into the dropins folder won't work. Alternatively, you could use the reporunnable task to transform the repository into the old runnable format.

Why make this change? These days, I would expect that most users are installing bundles via a repository such as Galileo or one offered by a product team. Unzipping files is so Eclipse 1.0. So this will allow our tests to replicate the environment that reflects the reality of our users. As well, as I mentioned in my earlier post, we really need to run our tests in parallel on more machines to speed up the build process. Having the test bundles available in a repository, eventually in a shared location, is a step toward that goal.

References

Test bundles should be packaged as a repo

Supported dropins formats

repo2runnable task

Note: The Eclipse and Equinox projects provide their JUnit test bundles in the eclipse-Automated-Tests-${buildId}.zip in the eclipse-testing/eclipse-junit-tests-${buildId}.zip file that is available with every build.

Galileo SR1 has left the station

2009-09-25T14:49:00.000-07:00

The Eclipse and Equinox teams are pleased to announce that our 3.5.1 release now available as part of the Galielo SR1 release. Congratulations to all contributors and committers whose hard work made this release possible!

Galileo

3.5.1 Readme

Eclipse

Equinox

You can also update to 3.5.1 using Help->Check for Updates

Enjoy!

Eclipse Helios: More repos, fewer zips

2009-07-23T11:01:00.000-07:00

In the 3.5 cycle, we introduced zipped p2 repositories in the build. These zips could be used to provision your target platform or update your install. We left the per-platform zips on the download page for Galileo. With 15 platforms multiplied by several permutations of features, and runtime versus source downloads, these zips consumed significant space on eclipse.org and the mirrors. Not to mention the fact that platforms other than Windows, Linux and Mac have very low download numbers.

For Helios, I've replaced all the platform specific RCP, JDT, PDE, CVS, examples and releng tools zips with p2 repositories specific to that feature. For instance, instead of 15 platform specific runtime RCP zips, there's a p2 source and runtime feature for each one. The SDK and Platform feature zips for each os.ws.arch combination continue to be built.

More information
How to Consume zipped repositories.
bug 280622

Galileo Release: Eclipse and Equinox 3.5 now available

2009-06-22T12:00:00.000-07:00

After a year of development, Eclipse and Equinox 3.5 are now available for download. Please put your feet up and enjoy our new release.

Galileo, Eclipse, and Equinox pages.

Every release is different and this year is no exception.

There's planning and committing to a goal.

Learning new things. See the New and Noteworthy and the readme.

Discussions with committers and community. How many rebuilds will there be?

Drama and angst.

Making new friends. We'd especially like to thank these people who really contributed to the success of this release.

Other Eclipse friends decide to see what's behind a new door.

Some days are a blur.

The final steps at the end of the release seem to take forever.

But the end is sweet.

Congratulations to the Galileo teams on the release. I hope everyone takes time to relax. Because it won't be long before have to lace up your shoes and get ready to run towards Helios!

Adventures in Publishing

2009-06-19T07:51:00.000-07:00

For Eclipse 3.5M7, we changed the build to take advantage of the new p2 publisher to to simplify the creation of the platform, RCP and SDK zips. Why switch to the publisher?

Metadata is generated on the source when pde build is invoked, instead of after the jars are built.

The publisher provides better support for the p2.inf

The metadata generator tasks are being deprecated

The publisher makes adding a new platform to the build much easier because metadata is generated for the root files. (We added five new platforms in the 3.5 cycle).

Also, the Equinox team also wanted to test the publisher in an active build environment and iron out any issues this might reveal. Similar to how Equinox is the reference implementation for OSGi, platform releng is the "reference build" for the Equinox team ;-).

Previous to using the publisher, we built the sdk feature and the associated root file feature to construct the zips available on our build page. Root files are just files that reside at the root of the eclipse install such as the eclipse executables, config.ini, eclipse.ini and license files.

To switch the our build to using the publisher I implemented the following steps

1) Set p2.gathering=true in the build.properties of the builder for our master feature. The master feature contains all the bundles and features we compile in the build. I also set skipMirroring=true, since we'd like to continue to control the mirroring aspects later on in the build.

2) Remove the call the p2.generate task after your bundles are built. While using the publisher, the metadata is generated when pde build is invoked in your headless build. So you don't need the separate generate call anymore.

3) Switch the SDK a feature based to product based build. This isn't necessary for most projects that are switching to the publisher. However, the Eclipse SDK is a collection of artifacts for many platforms and product builds make life easier. We also had to to write a p2.inf file to include some platform specific bits into the product build since the PDE UI's product editor has support for four platforms. We build 16! There's a bug open to support more platforms in product files, hopefully this will be addressed in 3.6.

4) Run the appropriate p2 publisher task. In our case, since we have product builds, I run the p2.publish.product task to publish metadata for the products to the repository.

<p2.publish.product flavor="tooling" repository="file:${reposource}" productFile="${eclipse.build.configs}/sdk/builder/sdk.product" compress="true">
<config os="win32" ws="win32" arch="x86" />
<config os="win32" ws="win32" arch="x86_64" />
<config os="win32" ws="wpf" arch="x86" />
<config os="linux" ws="gtk" arch="x86" />
<config os="linux" ws="gtk" arch="x86_64" />
<config os="linux" ws="gtk" arch="ppc" />
<config os="linux" ws="gtk" arch="s390" />
<config os="linux" ws="gtk" arch="s390x" />
<config os="linux" ws="motif" arch="x86" />
<config os="solaris" ws="gtk" arch="sparc" />
<config os="solaris" ws="gtk" arch="x86" />
<config os="macosx" ws="cocoa" arch="x86" />
<config os="macosx" ws="cocoa" arch="x86_64" />
<config os="macosx" ws="carbon" arch="x86" />
<config os="hpux" ws="motif" arch="ia64_32" />
<config os="aix" ws="motif" arch="ppc" />
<advice kind="featureVersions" file="${buildDirectory}/finalFeaturesVersions.properties" />
<advice kind="pluginVersions" file="${buildDirectory}/finalPluginsVersions.properties" />
</p2.publish.product>

5) Update any custom build scripts with the publisher targets. The pde build included in 3.5 will generate this automatically for you. However, if you have bundles where build.properties indicates custom=true, you'll have to update your static build.xml files to include the new publishing parts. We use custom build scripts for our doc and swt bundles. See this patch on bug 266488 for an example. Basically, you're adding the following to the init target of your build.xml.

<condition property="p2.publish.parts" value="true">
<istrue value="${p2.gathering}">
</istrue>
</condition>

and then this additional target.

<target name="publish.bin.parts" depends="init" if="p2.publish.parts">
<antcall target="gather.bin.parts">
</antcall></target></pre><param name="destination.temp.folder" value="${build.result.folder}">

<eclipse.gatherbundle metadatarepository="${p2.build.repo}" artifactrepository="${p2.build.repo}" buildresultfolder="${build.result.folder}" targetfolder="${build.result.folder}/${full.name}">
</eclipse.gatherbundle>
</target>

After these steps are completed, the build proceeds as normal to provision the zips from the repository using the p2 director.

Further References

If you're contemplating switching to the publisher, these documents are useful references. Our build is quite complicated with it's 16 platforms and associated launchers, the transition for most teams will be much simpler than our scenario.

The meta bug for the changes to reorganize the Eclipse and Equinox build to use the publisher.

Wiki article on the p2 publisher

Wiki article on customizing metadata

Ian's blog entries about the publisher 1 and 2.

Categories with Composite Repos

2009-05-21T11:50:00.000-07:00

Categories are groupings of elements that are available for installation in the p2 user ui. For example, the categories in the Eclipse and Equinox site look something like this...

Ensuring that categories are generated in the content.jar has always been a bit tricky. You can generate a buildtime site.xml that's used to specify the categories which is passed as an argument to the generator. However, this site.xml isn't actually used in the repo because that's old update manager technology. So 2007. You can also add the category name in a p2.inf. Again, not the most intuitive approach.

Today, John Arthorne proposed an interesting solution to this issue in bug 277359 that doesn't require changes to the build scripts. The trick is to add a child metadata repository to your composite repository that only specifies your category IUs. The steps are as follows:

Add a "categories" directory to your composite repository

compositeArtifacts.jar
compositeContent.jar
I20090518-2000/
I20090519-2000/
I20090520-2000/
categories/

In the categories directory, add a content.jar that specifies the IUs of the of the categories you want to display. For the Eclipse project's SDK category, the content.xml looks something like this...

<unit id="org.eclipse.sdk.ide.categoryIU" version="0.0.0">
<properties size="2">
<property name="org.eclipse.equinox.p2.name" value="Eclipse SDK">
<property name="org.eclipse.equinox.p2.type.category" value="true">
</property>
<provides size="1">
<provided namespace="org.eclipse.equinox.p2.iu" name="org.eclipse.sdk.ide.categoryIU" version="0.0.0">
</provided>
<requires size="1">
<required namespace="org.eclipse.equinox.p2.iu" name="org.eclipse.sdk.ide" range="0.0.0">
</required>
<touchpoint id="null" version="0.0.0">
</touchpoint>

The final task is to add the child repo "categories" to your compositeContent.jar in the root of your composite repository. You can use the p2 ant tasks to add the child repo or modify the CompositeContent.xml directly.

<children size="4">
<child location="I20090518-2000">
<child location="I20090519-2000">
<child location="I20090520-2000">
<child location="categories">
</children>

For more information, see bug 277359, the Eclipse and Equinox projects' integration build repo's categories content.jar and compositeContent.jar.

Ada Lovelace Day: One day late

2009-03-25T10:34:00.000-07:00

As Gorkem mentioned, yesterday was Ada Lovelace day. Thank you Gorkem for mentioning me among women in the Eclipse community. There are a few more I'd like to thank for their excellent work.

Kim Horne is uber talented Eclipse UI developer who recently moved on to work at RIM.
Sonia Dimitrov is an amazing release engineer who now works on Jazz.net by day, while playing violin by night.
Carolyn MacLeod is a very accomplished SWT committer who is an authority on accessibility.
Susan McCourt is responsible for all the work with the P2 user ui, and in the past provided her many talents to the Platform UI team. The p2 user ui is substantially changed in 3.5 as described in today's talk.

Unfortunately, I can't think of many more women in the eclipse community, although I'm sure there are quite a few more :-). (Please add more in the comments or in your blog). Only about 2% the people in most open source communities are women. This makes me sad. Why does gender matter? There have been many discussions at eclipse with respect to diversity in terms of company representation among committers. Diversity in terms of gender is important too. Diversity lets us see things from an different viewpoints and that's healthy for our community.

In Canada, over 60% of new medical school graduates are women, so obviously it's not an issue with women not having the prerequisites to get into engineering and CS. They simply don't choose to enroll in these degrees. Some of the research regarding this issue can be found here.

So what are steps that we can take as a community to ensure that the committer class of 2020 has more women?

Talk to your the kids in our your life about working in open source and how much you enjoy it. Computer science is often perceived as a solitary pursuit, when we all know the truth is that the work is very collaborative. Emphasize the community aspects, and how we all work together to solve problems.
Be a mentor. There are many kids in the community who don't have a exposure to a role model who works in the high tech sector. Therefore, they don't know anything about the industry other than the stereotypes. There are many opportunities to volunteer at local schools for career day, helping kids learn to read, or develop math skills. Some companies such as IBM sponsor a camp each year to expose middle school girls to science and technology. Volunteering at this camp allowed me to get paid to build Lego Mindstorms robots for a day. I highly recommend it!
Throw away gender based stereotypes. Don't assume your 12 year old niece won't want to learn how to compile a kernel, solder a board, or read a book about web design. You have to start them young :-) Don't call young girl who is interested in engineering or science "geeky", "a tomboy" or "weird". It's normal.

The purpose of Ada Lovelace day was to for female bloggers to write about a women in technology who inspired them. Here's a list of some other people that have inspired me even though I haven't met them in person.

Valerie Aurora was one of the first female Linux kernel committers. She is an expert on Linux file systems and writes on women in open source and building communities.
Kathy Sierra is the co-creator of the O'Reilly's excellent Head First line of books. She is also a well known speaker, instructor and blogger who has written on how create users who are passionate about your products.
Scienceblogs is an aggregator for scientists who blog about new research in geology, climatology, medicine, math, physics and many other new frontiers of science. Many of the female bloggers write about how they are breaking down gender stereotypes in the ivory towers of academia. Very interesting!

Slicing and dicing the p2 way

2009-03-03T11:48:00.001-08:00

We've traditionally used the packager to craft the features that are available on our download page from the signed bundles in our master feature. However, the packager isn't very efficient because it unzips all of the input feature to the packaging process, regardless of the bundles that are actually needed. Also the packager can be confusing for new users to configure. The packager also doesn't include metadata in the resultant zips. As my neighbour Pascal says, metadata matters. We'd like for people to reconsume the metadata that we create during the build instead of recreating it, possibly with errors.

In the M6, the p2.mirror task in the org.eclipse.equinox.p2.repository.tools bundle was introduced. This task provides a much more flexible and efficient mechanism for slicing and dicing bundles from a repo into a smaller repo. For instance, to assemble the components of the Equinox SDK from a repo, this command will do the trick:

<p2.mirror source="file://${buildRepo}">
<destination kind="metadata" location="file://${featureTemp}" name="My Equinox repo" format="file://${buildRepo}" />
<destination kind="artifact" location="file://${featureTemp}" name="My Equinox repo" format="file://${buildRepo}" />
<iu id="org.eclipse.equinox.feature.group" version="" />
<iu id="org.eclipse.equinox.source.feature.group" version="" />
<slicingOptions platformFilter="true" includeOptional="false" includeNonGreedy="false" followStrict="true" />
</p2.mirror>

This resulting content will include all the bundles associated with the org.eclipse.equinox.feature.group and org.eclipse.equinox.source.feature.group IU's as referenced in the content.jar. The version of these IU's is not specified which means that the highest version will be selected from the repo. Conversely, you could specify a version. The platformFilter="true" means that all platform specific fragments associated with this iu will be provisioned.

A simple and fast slicer. For the low low price of $19.95. Wait, it's free. Try it out today.

For more information, see

bug 262083

bug 265208

Implementing composite repos in your build

2009-02-13T12:00:00.000-08:00

As DJ mentioned, composite repository support is included in 3.5. Our I-builds composite repo looks something like this...

compositeArtifacts.jar
compositeContent.jar
I20090210-0950/
I20090211-0900/

with a directory for each child repo such as
ls I20090211-0900/
artifacts.jar
binary/
content.jar
features/
plugins/
sdkinstaller.properties

Composite repositories allow you to identify which bundles are associated with each build in the repo. This allows you to cleanup your repositories more easily and avoid the wrath of the webmasters. How is this implemented in the build? As a neigbourhood committer would say, let me tell you a story......

One of the most important steps in our build is to create a master feature of all bundles and features that can sign it at the foundation in a single step. Once this feature is available, we extract it to a source location and publish metadata to a repo.

<p2.generator source="${reposource}" compress="true" append="true" flavor="tooling" metadataRepository="file:${repo}" artifactRepository="file:${repo}" metadataRepositoryName="${p2.repo.name}" artifactRepositoryName="${p2.repo.name}" publishArtifacts="true" p2OS="linux" mode="incremental" />

The next step is to run some packaging steps, then use the mirror application task to mirror the metadata and artifacts from the repo to the child repository. Why not just copy the bundles from the repo to the child repository instead of using the artifact.mirror task? One of the things that we want in our build is consistency. If a bundle in build A has the same version and qualifier as the bundle in build B, it should have the same content. Inconsistent bundles are scary.

How can a bundle have the same name but be different?

New compiler changes the byte code
New certificate changes the manifest
Conditioning process changes the timestamp in the manifest
A bundle has a compile error because of one the bundles it depends on has a bug. The dependancy is fixed, but the tag of the original bundle remains unchanged.

So we mirror the metadata and the artifacts instead of a simple copy.

<property name="buildRepo" value="${updateSite}/${buildId}">
<mkdir dir="${buildRepo}">
<p2.metadata.mirror source="file:${repo}" writemode="append" destination="file:${buildRepo}">

The artifact.mirror task has the baseline argument which refers to the existing composite repo. This means that the jars in the baseline repo will be used if the same jar exists both the baseline and the source repo. The new jars won't be used. This replicates the experience that a user will have when updating to the latest build. If the same jar already exists in their install, they won't download a new bundle.

<p2.artifact.mirror source="file:${repo}" baseline="file:${updateSite}" destination="file:${buildRepo}">
<copy todir="${buildRepo}">
<fileset file="${eclipse.build.configs}/../../extras/sdkinstaller.properties">
</fileset>

The next step is to create the composite repository
<p2.composite.artifact.repository.create location="file://${updateSite}" name="${p2.repo.name}" compressed="true" failonexists="false">
<p2.composite.metadata.repository.create location="file://${updateSite}" name="${p2.repo.name}" compressed="true" failonexists="false">

and add the child repository (current build) to the composite repository. The compositeArtifacts.jar and compositeContent.jar will have entries for the child repositories.

<children size='2'>
<child location='http://download.eclipse.org/eclipse/updates/3.5-I-builds/I20090210-0950'/>
<child location='http://download.eclipse.org/eclipse/updates/3.5-I-builds/I20090211-0900'/>
</children>

When we run the p2 director to provision the build zips, we provision from the composite repository.

Consistent metadata and artifacts ensures happiness all around.

This solution isn't perfect yet. I'll also be using the p2 team's comparator to provide warnings for certain scenarios . See bug 263272

Eclipse 3.5 M5 now available

2009-02-03T07:42:00.001-08:00

The 3.5M5 Eclipse and Equinox builds, as well as the new and noteworthy have been replicated to eclipse.org. The milestones p2 repo has the M5 bundles available.

M5 wasn't without drama. Late Friday afternoon, the UI team asked for a rebuild toward 3.5M5 to include a new splash screen. How could this go wrong? A rebuild with one file change. What could be simpler?

I woke up on Saturday morning confident that the build would be ready to promote. Instead of quality time with my laptop I'd be able to spend time snowshoeing with my favourite mathematician. Unfortunately, this was not to be. The build was missing the eclipse executables (eclipse.exe, eclipsec. exe etc). Hmm, I don't think this is a cosmetic bug. One file change and the executables went away? This seems like overkill.

When running the p2 director to provision the bundles for the build from the repo, there were signing errors in the .logs. I ran a test build with signing. The build had the same error. I ran a test build without signing. The executables were back. I ran jarsigner -verify on the bundles on a signed build. The junit 3.8.2 bundle had a signing error in the manifest. Interestingly enough, Denis had changed the signing certificate on eclipse.org on Friday.

At this point I suspected the problem was that the Orbit bundles were signed by the old certificate and the new bundles that we had just compiled in our build were signed in the old certificate. We resign the Orbit bundles in our build. (I've opened this bug to avoid this in the future).

Martin Oberhuber and David Williams ran a Orbit build on Sunday night which was signed by the new certificate. I ran a test build with this new build. The executables were back! Monday morning I promoted an Orbit build to Stable, and started a new build toward M5. Andrew Niefer determined that the root cause of the problem was that the junit bundle had a nested jar with a bogus signature. The end was near of this milestone saga! I could finally start releasing my patches that I had prepared for M6.

I was pinged on IRC by a certain PDE committer from Austin who will remain nameless. "Kim? Is there another build toward m5?" This PDE bug was approved by the PMC for inclusion in M5 yesterday afternoon. Another rebuild.

Here are the bugs with the details.

Promote 3.5M5
Certificate will expire within six months.
JUnit jars should exclude nested jars from signing and packing
[jarprocessor] Should we be signing nested jars?

I'll celebrate the release of M5 with a cookie. Enjoy.

Kite Club: Committer Edition

2008-05-28T06:39:00.001-07:00

Here in Ottawa, everyone is looking forward to summer vacations after an extremely busy release cycle. My good friend Sonia has introduced us to sport kiting.

Flying a kite is a very relaxing way to spend lunch hour - thoughts of builds and bugs are swept away. Sonia can really make the kite dance.

I just try to keep it up in the air without crashing spectacularly. In some ways, it's similar to being a buildmeister...

Some people see kiting as an extreme sport. Others go kite skiing.

The other day, we discovered that Prism offers a p2 sport kite. It is described as follows

STYLUS P.2
The P.2 develops impressive pull in a strong breeze but responds with crisp precision to your inputs. It’s astonishingly easy to recover from a collapse or a crash due to its oversized air inlets, and when the wind picks up it’ll really scream along. Want more power? Stack one, two, or three more P.2’s in a train and get ready to go for a ride!

I look forward to seeing p2, Eclipse 3.4 and Ganymede take flight.

Platform-releng endorses p2, not paddles

2008-03-14T15:23:00.000-07:00

Zx has suggested that the Eclipse project's releng team has become soft. What? In fact, we're in pretty good shape due to the amount of shovelling we've done to move the 4m (13 feet) of snow that has fallen in Ottawa this winter. We don't have to resort to Photoshop for extra muscle tone :-)

I did give out out a clown nose this week. It wasn't well received...although in the process I learned some new French vocabulary from a certain Equinox committer. Integrating p2 into the build was really a group effort. We are using the p2 code compiled in the build to build the SDK..so there are bootstrapping issues. It would have been ideal to have more time to test the integration but with EclipseCon immediately followed by M6 we had to get in this week's build. I'll write later on how we are transforming our build process with p2. It promises to alleviate many pain points. However, as always, change reveals many implementation details. For other teams, the transformation will be much much simpler. We now have a build that works with p2 goodness. In the end, that's all that matters.

I saw a preview of Pascal's p2 talk this afternoon and I'd highly recommend taking the opportunity to attend it at EclipseCon and learn more.

As for using paddles as a deterrent for build breakage...well eclipse.org is rated PG. I'll leave the paddling activities to other websites...

Eclipse 3.4M5 now available

2008-02-08T12:44:00.000-08:00

Eclipse 3.4M5 is now available for download . Please peruse the New and Noteworthy here.

M6 promises to be even more dramatic milestone, with plans for new Equinox and PDE bundles to hatch from incubation and into the SDK.

Happy 6th Birthday Eclipse!

2007-11-07T05:48:00.004-08:00

Eclipse is six years old today.

From
1.0 to wow!

Happy birthday!

Eclipse 3.3.1.1 now available

2007-10-26T06:20:00.005-07:00

Eclipse 3.3.1.1 is now available.

Q. What is Eclipse 3.3.1.1?

A. It is Eclipse 3.3.1 with six additonal bug fixes as listed in the readme

Eclipse 3.3.1.1 is NOT

Eclipse 3.3.1: Extended edition

Eclipse 3.3.2

Platform 9 3/4

Q. How are fixes backported to a maintenance stream?

A. During each build we tag both the map files and the builder projects with the build id such as I20071023-0800. This insures that each build is repeatable. If we need to back port fixes to release, I just branch the releng project from the tag and the developers branch the relevant projects, release their code, and update their map in the new branch.

Q. Why do some of the features in 3.3.1.1 have feature versions listed as 3.3.2?

A. The marketing name of "Eclipse 3.3.1.1" doesn't need to correspond to plugin and feature versions. We could start naming our releases in step with the hurricane names, for instance Eclipse Melissa. However, if you looked at the components of Eclipse Melissa, they would still adhere to the versioning numbering guidelines.

For instance, Eclipse 3.3.1.1 has the following feature versions
cvs -> 1.0.1
equinox -> 3.3.1
jdt -> 3.3.1
pde -> 3.3.2
platform -> 3.3.2
rcp -> 3.3.2
sdk -> 3.3.2

When we release the first bug fix in a new stream of a release, we increment the service version of the bundle and the feature that contains it.

Now on to Eclipse 3.4M3 :-)

Stay out of the cold with the latest eclipse I-candy

2007-03-13T13:44:00.000-07:00

After all the excitement of EclipseCon, I arrived home to realize that although Ottawa currently lacks Santa Clara's warm breezes and sunshine, spring is definitely on the way because ...
1) The melting snow decided to visit my basement
2) Eclipse 3.3 M6 is next week

M6 represents the API freeze for the Europa release of the top-level Eclipse project. In fact, at this juncture, teams must ask the PMC for approval to make API changes.

If you are adopting 3.3 components as part of the Europa release or for your commercial project, it's a good idea to take a look our integration builds, not just milestone builds. Consuming your dependancies each milestone means that you are in only in a position to understand changes after the milestone has shipped. Taking a look at the builds in the weeks leading up to a milestone allows you to provide feedback on new functionality through bugzilla or mailing lists, specify how it impacts your use case and offer to help out :-) while the code is still under development.

The latest integration build is available here.

Of course, as we gear down to the Europa release at the end of June, the number and scope of changes will start to wane. Why? Submitting major new functionality close to the shipping date puts the release at risk. We like to ship and then everyone takes vacation. It's a tradition around here.

To mitigate against the temptation to release risky code, the rules of engagment in an end game plan specify increasing levels of sign off and verification for changes as we march toward Europa release date. This ensures that there is a conversation among members of the team regarding whether a change should be implemented, the associated risks and the possible impact to downstream teams, instead of just one person with the fervent wish to close another bug.

The M6 build menu looks something like this...

Monday starts off with a series of builds toward a test candidate.

Tuesday is test day, where people test the Monday's test candidate.

Wednesday is another build day where teams submit fixes to the issues they discovered during the test pass.

Thursday we have a final build and then ask teams for sign off. Inevitably, there is a rebuild to address a late breaking issue.

Eclipse 3.3M5 now available

2007-02-10T06:32:00.000-08:00

As Dejan mentioned earlier, many people were anxiously waiting the release of Eclipse 3.3M5. Milestone week...end is always dramatic and the 2007 edition is no exception. Sexier forms, SWT on the splash, a new launcher, a shiny new pdebuild that fetches prebuilt bundles via http a la Orbit - M5 is more exciting than an astronaut love triangle.

These and many other new goodies are documented in the New and Noteworthy.

Download M5 from you friendly neigbourhood mirror.

Who will make a splash at Eclipsecon 2007?

2007-01-30T16:52:00.000-08:00

And by splash I don't mean who will jump in the hotel pool. Who will be the lucky ones to have their smiling faces appear in an Eclipse SDK vanity build? Last year it was Steve and the Netbeans girls In 2005, the winner of the Eclipsecon trivia contest had her own Daniela build. Whatever happens, it will be very exciting.