I am sure there is much I do not understand,
also, and not sure we want to have a long "educate David discussion"
on this list, but I will make this last, wordy response to clarify what
little I know, and you can open a bug if you think there is one, or if
I am missing your point.
I've repeatedly said the Sim. Release
repo is not intended as a build target, and recommended projects use the
"original source" project's repositories. Knowing that many people
disregard my saying this and do it anyway, I thought a warning to this
list would suffice. It has been discussed in the Planning Council a couple
of times, and the projects and strategic members that make up the Planning
Council were unwilling to do the "extra work" required to try
and provide a one-build-repository-fits-all, when the intent of the Sim.
Release repo is to make things easier for end users to install, update
-- and most of all, discover -- functionality, since there is such a large
collection of diverse projects at Eclipse. Also, as far as I know, adding
a new platform (architecture) in a service release might break someone's
build (or processes). Plus, I think the Eclipse PMC was reluctant to add
an "Early Access" platform, to the "Sim. Release" repo,
since, honestly, it only started to completely come together a few weeks
before it was due, and being in the Sim. Release repo implies (to the Eclipse
Project) "ready for enterprise production use". Granted,
given enough time and resource, the Eclipse project releng team could have
made one "deliverable" for their own repository, and another
"deliverable" for the Sim. Release repository ... but, it did
not seem a high priority, since it mostly effects those who a) use Sim.
Release repo to build against, even after being told "do so at your
own risk" and b) only effects those who specify "build all platforms,
except <these>" and I get the impression most projects specify
"build <these> exact platforms", such as, Windows, common
Linux distributions (architectures), and/or Mac OSX.
Now, after all that defensiveness, don't
get me wrong, I am not arguing "everything is perfect and as it should
be" ... as I said, the "the least worst alternative" given
the timing and constraints we have to live with, not to mention I am sure
there are things I do not understand about the reasons people do what they
And, by all means, if I have entirely
missed your point and rambled on about something unrelated, and there is
some specific bug you are talking about, other than in our choices of what
to spend effort on, feel free to open a bugzilla entry in Platform, Releng
and we can continue the discussion there.
Especially apologetic to you, Thomas,
since this complicated you fixing a long standing bug in the b3 aggregator
for "us" (442191).
Much thanks for fixing that.
Thomas Hallgren <thomas@xxxxxxx>
09/28/2014 06:17 AM
Luna is inconsistent. Features are referencing non-existent fragments!
What I didn't understand when this happened the last time
and still don't, is why the references were added but not the targets that
they reference. That's like saying - let's deliberately break all builds
that try to resolve the references that are there.
But of course, that doesn't help anyone not part of the "Sim. Release"
and would therefore would not be reading this list on a regular basis.
[To summarize, the Platform team wanted to add this "early access"
platform to their own Luna repository, but not the "Sim. Release"
repository for Luna Service release.
In Mars, it is part of the Sim. Release repo. We knew this could complicate
other's builds ... having to filter it out in Luna, but not in Mars ...
but, it was felt the "least worst alternative" given the timing.]
Apologies for the inconvenience. Please help spread the word.
On 2014-09-28 08:31, Thomas Hallgren wrote:
> Our builds for the b3.aggregator has started failing. Seems the org.eclipse.e4.rcp
feature now references fragments
> for ppc64le but those fragments cannot be found in Luna.
> Feature org.eclipse.platform:eclipse.feature$4.4.0.v20140925-0400
> Feature org.eclipse.e4.rcp:eclipse.feature$1.3.100.v20140909-1633
> This problem is very likely to affect other Buckminster builds.
> Are these bundles available from somewhere else? If not, then please
remove the references to them ASAP.
> - thomas