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

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

Jay, 

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. 

Jeff

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

01/30/2006 10:10 AM

Please respond to
Equinox development mailing list

To	equinox-dev@xxxxxxxxxxx
cc
Subject	[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
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev