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 do. 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. Sincerely, From: Thomas Hallgren <[email protected]> To: [email protected], Date: 09/28/2014 06:17 AM Subject: Re: [cross-project-issues-dev] Luna is inconsistent. Features are referencing non-existent fragments! Sent by: [email protected] 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. Why not just add all of it or not add it at all? - thomas On 2014-09-28 10:30, David M Williams wrote: Sort of a re-incarnation of those bugs ... but, this time it was a conscious decision, and we tried to spread the word via this list: https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg11040.html https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg11042.html 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. From: Thomas Hallgren <[email protected]> To: Cross project issues <[email protected]>, Date: 09/28/2014 02:41 AM Subject: Re: [cross-project-issues-dev] Luna is inconsistent. Features are referencing non-existent fragments! Sent by: [email protected] This bug is probably a reincarnation of https://bugs.eclipse.org/bugs/show_bug.cgi?id=337026 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=213437 - thomas 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 references: > org.eclipse.core.filesystem.linux.ppc64le:osgi.bundle/[1.4.0.v20140808-1353,1.4.0.v20140808-1353] > > Feature org.eclipse.e4.rcp:eclipse.feature$1.3.100.v20140909-1633 references: > org.eclipse.swt.gtk.linux.ppc64le:osgi.bundle/[3.103.1.v20140903-1936,3.103.1.v20140903-1936] > org.eclipse.equinox.launcher.gtk.linux.ppc64le:osgi.bundle/[1.0.200.v20140409-1208,1.0.200.v20140409-1208] > > 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 > > _______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
