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

EclipseCon Exercise Tuesday: 310K and counting

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!

Read more...

Eclipse Run Time was a Fun Time

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.

Read more...

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

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.

Read more...

Ten things I wish I'd known as young committer

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.

Read more...

EclipseCon Exercise: Vote for prize categories

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!

Read more...

Confessions for the EclipseCon Speaker

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.

Read more...

Better builds with Hudson, hardware and help

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

1. Checkout code from eclipse.org to an IBM build server.
2. Generate build scripts, compile code and create a master feature of all the bundles used in the build.
3. Copy master feature to eclipse.org for signing, copy back to IBM server when complete.
4. Run the p2 director to provision products and use repository tooling to slice out zipped repositories.
5. 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 :-)

Read more...