Re: [cross-project-issues-dev] Troubleshooting Orbit Bundle Use / Coordi

[David M Williams <david_williams@xxxxxxxxxx>]

I agree with Kim ... option 'd'.  I
think we can only expect synchronization at milestones .... and, that's
the only predictable build from Orbit, since we make and promote those
"on demand", since we often go for weeks with no or few changes.
 

Naturally, if there are some projects
that find that some bundles are especially sensitive to coordinate, then
those projects can and should coordinate well, but I think in the vast
majority of bundles for the vast majority of projects, there's no real
impact if qualifiers differ a little  week to week.  The worst
offenders, I think, are those bundles that both import and export the same
package (see bug
217724 for some possible future
relief). To my knowledge, org.apache.batik.transcoder
is the only one that does ... though, I'm sure there are others.

From:	Kim Moir <Kim_Moir@xxxxxxxxxx>
To:	Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date:	02/06/2008 03:37 PM
Subject:	Re: [cross-project-issues-dev] Troubleshooting Orbit Bundle Use /        Coordination Ideas

---

For our project, updating to the latest Orbit build on a weekly basis is
not warranted.  Also, the Orbit weekly builds are frequently deleted
which can result in build breakage trauma :-( Our approach has always been
to use the stable Orbit build that corresponds to that milestone or release.
  Or course if there are changes to bundles that we consume we test
them before the milestone.   

The Orbit team announces a stable build at the beginning of our milestone
week(+0).  For instance, David sent a reminder a few days ago

http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg01931.html

How about another option 
(d) All projects that rely on Orbit jars agree to step up to the appropriate
stable Orbit build each milestone.   If a team cannot step up to this
build, they should announce it to the cross project list.


Kim

Nick Boldt/Toronto/IBM@IBMCA
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

02/06/2008 02:32 PM

Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>

To	"Cross project issues" <cross-project-issues-dev@xxxxxxxxxxx>
cc
Subject	[cross-project-issues-dev] Troubleshooting Orbit Bundle Use /        Coordination Ideas

Recently, there's been some discussion around building products based on
Ganymede.

One of the issues that has been raised is the problem that occurs when
a product uses more than one piece in Ganymede, and those pieces BOTH use
the same Orbit bundles -- but different versions. 

I'm not familiar with the details of why OSGi has problems when it encounters
two versions of, say, Batik or Xalan, but suffice to say bad things happen,
and the simplest workaround is to ensure that everyone that relies on Orbit
uses the same version of any given bundle.

There are a number of ways that have been suggested for how to best manage
this and avoid product breakages. These include:

a) every project that relies on Orbit jars agrees to step up the the latest
bleeding edge Orbit release every time a new one is available (eg., weekly
or biweekly).

b) every project that relies on Orbit jars, if they cannot step up to the
latest release in a timely manner, will post a note to this list stating
their deviation from rule (a), and when they might be able to adopt the
latest. This will allow other projects using the same bundles to coordinate
timing so they stay consistent.

c) every project that relies on Orbit jars will post a list of the jars
they consume on their Ganymede/Signoff page, so others will know what they
require and can coordinate with those projects to align themselves. Optionally,
this could also include the version of those bundles as a way of ensuring
consistency. Granted, this is more labour intensive than (b), and implies
regular updates instead of (hopefully) infrequent announcements, but it's
also more informative. 

I put it to the group:

* Can everyone commit to (a) ? 

* In the event that you can't adhere to (a), would you prefer (b) (report
on deviation only) or (c) (report on status) as the cross-project communication
method? 

* Would (c) be useful (in addition to (b)) just for information's sake,
or is it overkill? And if you like (c), do you want to maintain version
#s in there too, or just bundle names? 

Cheers,

Nick
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev