Tuesday, April 7, 2009

Turning Freeloaders into Freehelpers

We have been entertained with a number of posts to the planet over the last while. It is a opportunity to think critically about what is great at Eclipse, and what details we can improve upon. Keep them coming.

I completely agree with the opinion that we need to find a way to increase the diversity on our projects and get more individuals working towards our greater goals. We saw many presentations at EclipseCon by some big companies making significant investments on software based on the Eclipse platform.

Yet a number of them do not "contribute" anything back to Eclipse.

Eclipse committers are measured exclusively by their code contributions. We have a great system in the dash project where commits are measured. If you have not committed any code into CVS in the last nine months you get the boot. Perhaps not literally, but some projects tend to run that way.

If I want to add a committer, we are pretty much limited to gathering a list of Bugzilla patches demonstrating their contributions of code to the project.

And that is where I think we can make some improvements. Committers do many more things than just write code. They test, they document, the manage builds, they answer newsgroup questions, they present at conferences, they track Bugzillas and so on and so on.

I imagine a contributor at a big company who consumes an Eclipse project. There are individuals who do many odd jobs to make sure the Eclipse project is healthy for use in their application. These are the resources we need to attract.

I especially like the ideas on Stack Overflow and their system of badges and reputation. I can see this working at Eclipse. Raise a Bugzilla? Answer a newsgroup question? Test an integration build on a specific platform? All this contributes to your project reputation.

Once you reputation is high enough, you are a committer. Code contributions need not be necessary, you are contributing to the overall health and well being of the project. You have demonstrated your dedication to the community.

As the non-code relationship is nurtured, perhaps these companies will feel inclined to eventually donate back some of their extensions and fixes in their fork back to the community at Eclipse.

Thursday, April 2, 2009

Shooting for the moon

The simultaneous release has been a huge success at Eclipse. Over the years, the June release has come to signify THE release date for the majority of the major Eclipse projects. This years Galileo will be the fourth Eclipse simultaneous release following Callisto, Europa, and Ganymede.

Right from the start, the name of the simultaneous release has been critical. It has become a brand in itself and has a huge following in all areas of our Eclipse community, from marketing to media to development.

We chose Galilean moons for the early releases. Io was due up to be the name of the fourth release, but given that "Io" looks a lot like the number "10" and "I/O", we went with the name of the astronomer who discovered these four moons.

Now that we are out of Galilean moons, the Eclipse planning council have finalized a formula for our releases going forward.

We have agreed to keep our tradition of using a moon within our solar system. We have also recognized it would be desirable to maintain an alphabetical order going forward, so that we recognize the "N" simultaneous release follows the "M" release.

This means that our next Eclipse simultaneous release in 2010 will be a moon starting with the letter "H". Oliver Cole has setup a doodle vote and give our community a limited set of "H" moons to vote on. We can also comment further on Bugzilla 271054.

We now have a strategy going forward to name the next nineteen Eclipse simultaneous releases.

Definitely shooting for the moon.

Wednesday, March 18, 2009

EclipseCon: Show me your Mac

The Galileo Simultaneous Release has almost reached the M6 milestone. This means API and UI freeze for many projects and our attention turns to some hard core integration testing.

The GEF and GMF teams have spent considerable time cleaning up some of the finer details in our graphical platforms, such as anti aliasing, line width, fractional line widths, curved lines and gradients.

It is pretty much impossible for our small team to test every diagram on every platform. We think have caught and fixed most of the issues, some of which where somewhat nightmarish.

Which brings a us to the topic at hand, our team has a distinct lack of Macintosh computers to test on. We have access to older PowerPC based Macs, but none of the newer fancy Intel based Mac notebooks.

As all you Mac users are testing and playing at EclipseCon with the latest and greatest, pay special attention to your diagrams. If you find anything, toss us a Bugzilla or drop me a line at anthonyh [at] ca.ibm.com. Testing with the latest Cocoa platform would be a bonus.

Wednesday, February 25, 2009

First Must Do for Galileo

Now that the Ganymede SR2 release is winding down and almost out the door. It is time to get thinking about getting our moons in order for the Galileo Simultaneous Release .

We decided this year to track all our must do items using Bugzilla. We are a little behind on the must do list, given a bunch of them were supposed to be resolved for the M4 milestone.

With a little Bugzilla housecleaning work, I was able to get our first must do Bugzilla resolved. We now have our list of Eclipse projects who have confirmed their intent to join the simultaneous release.

Next step is to get moving on some of the other must-dos that should have been done before M4. Everyone got their projects plans in the Eclipse XML format , their CQ complete , and builds running ?

One must do down, twenty one to go.

Monday, January 26, 2009

The GMF Super Ultra Slim diet

Following the very popular EMF Ultra Slim diet, the GMF Runtime is providing a GMF Super Ultra Slim diet in Galileo.

The Super Ultra Slim diet also quickly sheds those unwanted bytes to a reveal a new and slimmer GMF notational metamodel.

For a GMF Note:
  • Before 1064 bytes
  • After 384 bytes
So a 64% reduced memory footprint.

Overall memory savings depend on each particular shape. There will be more loss for shapes located inside canonical compartments. Those shapes may get as much as an 80% slimdown.

Similar to other diets, GMF users must reform and adopt new view factories to take advantage of the new diet. The new view factories are conveniently located in the package org.eclipse.gmf.runtime.diagram.ui.view.factories.optimal .

However, if you are happy with what you have, the original GMF view factories can be used without change. There are no breaking API changes for GMF to offer this diet.

Plan to start both the EMF and GMF diets to slim down your graphical editor.

p.s. Congrats to Alex Boyko on his hard work to make this diet a reality.