Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orbit-dev] Ready for WTP contributions?

David Williams wrote on 10/22/2006 08:18:31 PM:

> > > Otherwise I suggest we change the name that's in there to match what
> > > was released in Callisto.
> >
> > Point taken.  The way I was looking at these things is that they are
> > *new* bundles.  Teams can use them as needed.  In many cases the
> > original bundlings were "wrong" or inconvenient.  For example, we
> > shipped org.eclipse.equinox.servlet.api.  That is now javax.servlet
> > and javax.servlet.jsp.  We did this to better accomodate the
> > usecases and conventions put forward in Orbit.  It is not a breaking
> > change in that people can still get and use the old bundle with no
> > loss of function.
> Yes, for the logging example, though, I'm not sure BOTH bundles (old and
> new) could co-exist and still work right (e.g. if some system-wide
> Singleton is supposed
> to exist). And, we _might_ be able to get previous users to switch, but, I'd
> rather be prepared with a binary compatible story ... I think one transition
> strategy would be to also provide a new
> bundle with old name, and it simply import and re-export packages from a
> newly named bundle?  

There will certainly be issues like this that surface with or without Orbit and regardless of what names we choose (e.g., we are not the only ones producing bundled versions of these libs).  We should use this opportunity to reduce the brittleness of our configurations.  Of course this has to be balanced with pragmatics.

> > We have an opportunity here to establish and adopt best practices.  
> > We should take it.  To that end, a stake has been put in the ground
> > to define the naming and versioning conventions to be used.  The new
> > commons logging bundle follows those conventions.  Of course, we can
> > ammend/change the conventions as it is early days for Orbit.
> Yes, and being ultra sensative to compatibility with previous
> versions is one "best practice"
> we should be exemplary in ... and an example of how to "transition
> names" would be one
> such case.


> > This line of discussion raises an interesting question.  Does the
> > originating project have any particular standing different then the
> > rest of the consuming projects when it comes to bundling in Orbit.  
> > My personal view is no, we are all just consumers and are all
> > working together to create a coherent and consistent solution to the
> > third party library problem.  An approved library can be committed
> > to Orbit by any Orbit committer.
> Yes, any could commit, as long as others have veto rights as is
> required in Eclipse Foundation projects :)
> And, allowing any to commit also requires a very traceable history
> of what has
> been officially approved, which is why I think we need a
> log that points back to the original log showing approval.
> Or, at least, an easy to query bugzilla entry.
> For example, what if I wanted to ship a "product" or other open
> source project that used javax.servlet and javax.servlet.jsp
> other than word of mouth, how could I verify that it's been approved?

I totally agree that we should be able to point to the approval information.  The best source of this information is the Foundation's IP process and IPzilla.  Orbit can duplicate that information but it would not be authoritative.  One thing that must be absolutely guaranteed is that if it is in Orbit, then the Foundation *must have* approved it for use by *some* project.  Orbit changes nothing wrt the IP process.  Projects themselves still have to fill out a contribution questionnaire and get approval to use a thrid party lib.  Orbit simply captures and shares the work that goes on after approvals have been given.

> Also, I'm partially asking this question since this project seems a
> little different from others in that others are not considered "official"
> until they are "released". Is there a similar "release date" for Orbit?
> [Obviously, we could force there to be one, by saying so, but seems
> a bit odd, since
> the underlying project/products have already been released]. Or, are
> we in the odd postiion of saying these bundles are only released when
> an _Eclipse_ project that uses them is released?

Orbit should participate in Europa but you raise a good point.  Perhaps we have to come up with a way of identifying bundles that are "good to go".  If WTP (for example) wants to do a release in January, they will want to go with good Orbit bundles.  Note that other projects (e.g,. Equinox/Bundles) have similar issues.

> In summary, my main concerns in these long note are
> 1. How to keeping binary compatibility with what has come before?
> 2. How to we provide documented traceabiltiy?
> Thanks for any ideas ... or, talk on the phone later in the week.

Sure.  Its good to work through the issues here if for nothing else to form a basis for a phone discussion.


Back to the top