[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] How does code in "incubator" make it into "core" ?


There is no formal process as every case is different.  There are however lots of examples of code that has started in the incubator and moved to the mainstream.  The most notable of course is the OSGi implementation itself.  2 years ago the entire Equinox project was an incubator for an OSGi based runtime.  Various people from the Runtime team and other unrelated teams worked together to make a complete, sustainable, supported story for running Eclipse on OSGi.  In some cases (e.g, PDE) the impacts were many and deep.  In other cases they were minimal or non-existant.  We worked with the entire Eclipse project (and other) teams to ensure the impact was acceptable and that everyone understood the changes, what it meant to them and why they should care.    After many months of work and discussion, it was finally agreed that the OSGi based runtime was the way to go.

That was a relatively large effort.  More frequently the changes are smaller and more focused.  For example, after the OSGi adoption, a group of folks not on the runtime team proper worked to implement an OSGi constraint resolver that matched the they upcoming OSGi R4 standard.  Again, the code was adopted in the main stream after it was proven to be a reasonable approach (robust, performant, ...).  Other efforts include the work in eRCP that regularly feeds small changes into Equinox as well as the Server Side incubator in which the team is quite active at identifying problems and engaging the related committers to work towards a solution.

In other areas (e.g., JDT and UI) the teams take significant contributions that come with developers who become committers and continue the development and maintenance of the function being added.  In fact, this happened with Equinox as well.  Tom Watson came with the original OSGi code and is now the OSGi development lead for Equinox.

Your case with the security work is challenging because the changes you propose are very widespread.  Moreover, they are not just onetime code changes. These are modifications that require ongoing upkeep as well as more fundamental education of the developer community so that they understand how to write secure code.  The team in and around the security incubator has been doing a great job of analysis and of building tools to help with that analysis.  It would seem that we are at a critical juncture.  The ongoing analyze/patch cycle is clearly not tenable.  The tooling (e.g., SWORD4J) is there but not part of Eclipse (it is on AlphaWorks).  To move forward it seems a few things need to happen (this is not an exhaustive list)

- Education:  What is security? Why is security important?  What does it mean to individual developers?  How is it going to be tested?  Who is going to do the testing, checking, maintenance of the code...?  The community needs to understand, in excrutiating detail, exatly what is being proposed and how it will affect them.

- Tools.  SWORD4J is a huge leap.  For security to really take off at a fundamental level that kind of tooling needs to be fully integrated and provide immediate feedback.  The Eclipse IDE programming model is one of very lightweight edit/run cycles.  Having that bogged down or introducing a new step of batch security analysis will hinder the effectiveness of the developers (committers or contributors) and generally discourage them from doing that work.  The alternative is to have Security police who are responsible for particular components being secure.  They would be an integral part of the team and responsible for ensuring that the resultant components are secure.  In the near term the latter approach seems like the most viable.  Who would do this policing?

- Security model design.  It seems to be one thing to put in security code that manages standard Java 2 permissions but quite another to design a security model for Eclipse.  For example, the registry now allows clients to dynamically add contributions.  Should that be protected by a permission?  If so, what permission?  What should its scope be?  How will this impact the way clients write code?

Note that we have had similar challenges with dynamic plugin behaviour.  It has taken well over a year to get people to understand what it means to be dynamic and that they should care.  We still get folks making static assumptions.  Being dynamic is hard.  Developers are lazy.

This should not be taken as discouragement.  Rather it is a recognition that the security work has matured to the point where it looks technically feasible, the performance impacts have been measured, there are example patches available etc.  It is time for the next step -- adoption.


"Jay Rosenthal" <jrosenth@xxxxxxxxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

01/30/2006 10:10 AM

Please respond to
Equinox development mailing list

[equinox-dev] How does code in "incubator" make it into "core" ?

Pardon my ignorance..

Can anyone explain in detail or point me to some documentation on the process for getting code elevated from the "incubator" into the core  ?

I've looked at the info ( http://www.eclipse.org/equinox/incubator/howto.php ) but this seems incomplete and mostly just discusses "working in the incubator".

Particularly I am interested in getting the work that's been done in the "security work area" introduced into the "mainline".

Any help would be greatly appreciated.
Jay R.
IBM Software Group
Workplace, Portal and Collaboration Software
Workplace Managed Client, Security
"Yonder stands your orphan with his gun, Crying like a fire in the sun. " - Bob Dylan

equinox-dev mailing list