Get your bundles back

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

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

Further reading

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

Read more...

Building Open Source: the Backstory

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!

Read more...

Mozilla versus Eclipse build infrastructure

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?

Read more...

Number Nine: Happy Birthday Eclipse!

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.  

Read more...

At Eclipse we ship, we don't slip

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 :-)

Read more...

How to explain open source to your family

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).

Read more...

Ottawa Helios Celebration

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 :-)

Read more...

Bundles and Oranges: Dare to Compare

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.

Read more...

Webmaster kudos

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.

Read more...

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

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

Read more...

Eclipse Top Ten: #9 Teamwork

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

Read more...

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

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

Read more...

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

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

Read more...

Eclipse Top Ten #6: Eclipse is like family

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

Read more...

Where's the source?

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

Read more...

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

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

Read more...

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

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

Read more...

Architecture Council +2

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 :-)

Read more...

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

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

Read more...

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

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

Read more...

Eclipse Top Ten: #1 Transparency

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.

Read more...

EclipseCon Exercise Thursday: 570K in total

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!

Read more...

Ada Lovelace day at EclipseCon

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.

Read more...

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

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!

Read more...