[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] [eclipse.org-planning-council] Neon.3 Update Problems


I believe this kind of direction should be given by the planning council.  What you're stating is your opinion (or a suggestion for a change in the long established direction), but we've already heard David's opinion on this, and it was one of caution.  Having managed release trains for years, I put a heck of a lot of weight in David's informed opinions.  So at this point I don't feel we (you) should not be prescribing a new solution to replace the old solution, not until the planning council has determined and agreed that this new solution does in fact solve enough old problems without introducing more new problems compared to the old solution.   Of course I have no issue with discussing new approaches, but best we consider carefully any new path we take, and best we not prescribe a solution before its fully baked.  In other words, I'm cautioning you not to draw a final conclusion.  I've already pointed out some of the tricky questions that will arise, but they were far down in a long note, so I'll repeat them here:

Don't include Orbit bundles in your project's features.  Sounds like a great idea, but begs endless questions, and while solving a problem might well introduce more new problems than it solves.  The first question (as Carsten points out) is how do these things end up in a repository, and if they are in a repository somehow, how are they categorized?  It's hard to get them in and once you do, they're categorized poorly.  The next question is, how do they end up in the release train, if the projects that need them don't contribute them?   Directly from Orbit you say?  But which ones should be pulled in from Orbit and how is that discovered?   Are those the ones the projects have tested against? Then there is the question of whether an installation is deterministic if the bundle version isn't pinned?  It's not; it will depend on what's in the repos that are available at resolve time.  But Gunnar argues that even packages are not deterministic, which I think is false: if the feature pins the bundle version and the package requires the feature, then the pinned bundle is definitely in that package.  But regardless, Gunnar's important point is that the runtime wiring seems kind of non-determinstic, and while uses constraints might help, who the heck understands those well, what tooling produces it correctly for us, is that nicely integrated in PDE, and will it be properly maintained (in contrast to lower bound constraints which you can pretty expect will remain on whatever stale version they were initially set to).  This may well be the right direction in which to go, but getting there isn't going to be even half the fun...


On 31.03.2017 11:53, Mickael Istria wrote:
On 03/31/2017 09:25 AM, Ed Willink wrote:


It is currently necessary to rebundle Orbit bundles because Orbit is not included in the xxx release repo.

One can (and should) include the Orbit bundles in the p2 repo, but not include them in the feature. So the dependencies are available at install-time, but not constraining the resolution. The category.xml easily allows to add any bundle to a p2 repo, those could be Orbit ones.

Mickael Istria
Eclipse developer for Red Hat Developers
My blog - My Tweets

cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit