>Do Eclipse Projects need to roll out Patches faster?

>Large scale software projects like Fedora, Debian, Ubuntu, GTK, KDE, MySQL, and numerous others have a good response time in answering and supplying critical fixes that are affecting their users. However, the various Eclipse projects have a varying degree of success when responding to similar issues. In particular, with the latest release of Ubunutu there is a known problem with some button handling and GTK with Eclipse. Some say it’s a GTK problem other’s say it’s an Eclipse problem. However there is a fix in place, but unfortunately it is only currently available for 3.6. Some of the above mentioned distributions have gone and back ported the patch, but there are still numerous people that get their distributions from Eclipse.

The Eclipse developers knew about the problem before the release of Karmic Koala that contained the upgraded GTK which the eclipse platform has problems with in 3.5, and they could have had a patch ready to go on the day of release. I realize that we only have so many resources, but it is stumbles like this that I think give us a black eye now and then. With P2 we have the ability to role out patches in a more timely manner. Unfortunately, currently the earliest somebody can get this patch is either to roll it themselves, or hopefully it’ll be include in the next maintenance release (Feburary time frame).

Part of building a community is making sure that you respond timely to it’s needs. Bugs of this sort should be given higher priority than they sometimes are. If this port is in the works, then we need to announce it in as wide a forum as is possible. Responding to critical useability issues should be a priority of every project. With out your users, there is no community and no project.

Advertisements
This entry was posted in eclipse, open source, ubuntu. Bookmark the permalink.

5 Responses to >Do Eclipse Projects need to roll out Patches faster?

  1. >Until we have independent developers that care about downstream users, this is going to happen. Eclipse developers, especially those on the platform projects, are too focused on their own needs.

  2. David Carver says:

    >@Doug, Yeah I agree…if it doesn't affect them directly, their typically isn't an urgency. We have the power, but do we have the will to implement it with out a lot of negative push back, about time, and resources. Which I think is used as an excuse way to often.

  3. >It does not merely affect Eclipse users downstream, but also downstream developers… Any project based on RCP 3.5.2 is affected by this bug for the release they make. The Bioclipse incarnation of the problem is reported here.

  4. Kim Moir says:

    >If there's a fix in a maintenance stream, the maintenance build can be consumed. You don't have to wait for the release. Alternatively, you can apply the patch from bugzilla in your workspace and export the bundle.Releasing more often means more work. This means dropping other items, such as items on the Helios plan.The concept behind the coordinated release is that there is a level of interoperability between the projects. If we go back to releasing at random times, this interoperability will diminish to the detriment of the community.Ultimately it's about resources and priorities. We have very finite resources, and infinite bugs 🙂

  5. David Carver says:

    >@Kim, while I would normally agree, I think this particular bug is of some more importance than standard SR bugs. In particular it causes numerous items not to work with GTK 2.18 besides the buttons. If such a item were to affect say Windows XP, or Vista there would be a great urgency to roll it out sooner, rather than later.If the GTK users and platform were a larger percentage of the Eclipse base, then I still think this would be addressed quicker. We have the ability to do it, it's just a matter of making it a priority. And really, having a Patch stream that is available and deployed automatically weekly can't be that difficult. Other Open source projects of significant size and constrained resources are able to do it, eclipse should be as well.Note I did not say to get rid of the Simultaneous release, that is a good thing, I just think the SR process needs to be addressed and allow patches to be made available to the community much sooner. Still have a simultaneous SR release, but respond to the community quicker in these special cases.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s