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