[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[mdt.dev] Re: Galileo build failed
|
I know this is long, but please bear with me. :)
--
Well, it all worked great until Galileo started... but yes, I agree. The
current implementation is flawed.
So, in order to split <=3.4 from >=3.5 sites, we'll need to update
everyone's feature.xmls to point at a new location, and start publishing
into unique sites per project? I can work on fixing the publishing
stuff, but I don't have time or commit rights to update everyone's
features in HEAD.
We could do:
/modeling/emf/query/updates/galileo/ (for releases)
/modeling/emf/query/updates/galileo/interim/
/modeling/emf/query/updates/galileo/milestones/
Or can we merge milestones and interim into a single site, called
"weekly", like Mylyn does?
So, simpler:
/modeling/emf/query/updates/galileo/ (for releases)
/modeling/emf/query/updates/galileo/weekly/ (everything else)
Or even:
/modeling/emf/query/galileo/
/modeling/emf/query/galileo/weekly/
Or to be more numerically sequential:
/modeling/emf/query/e35/
/modeling/emf/query/e35/weekly/
Can someone open a bug and spec out what you'd like to see?
I suggest using the Modeling > Cross-Project bug component so that all
the project leads will be automatically cc'd. From there I'd hope that
they'd notify their subprojects to update their features (eg., by
opening child bugs).
We need to also decide on whether to keep more than one version on the
update site at a time. Currently, I keep 2-3 milestones and interim
builds per branch; that may be overkill, if we only care about the
latest release or latest weekly interim/milestone build. If we only need
2 builds at any given time for a specific project & branch, then the
sites become much simpler & smaller.
(The only counter-argument I can think of to the one site per subproject
idea is that p2's list of update sites will become MUCH longer when
people install Amalgam or the Modeling Tools bundle (Galileo version).)
Nick
Richard Gronback wrote:
Well, I suspect some magic cleanup script gone wild.
IMHO, sharing sites among components/projects is bad, as is having multiple
versions of a particular release type on a site. I mean, how often does
anyone really need multiple S, I, M, or even N builds? For that matter, why
not even split out R builds into version-specific spaces, leaving the latest
one to the /releases location?
For everything else, let people use an archived repo zip if they need it.
Best,
Rich
On 2/18/09 8:14 AM, "Christian W. Damus" <give.a.damus@xxxxxxxxx> wrote:
I don't understand. I haven't promoted any builds, lately. The last
build that I promoted was my M5a build, and that went smoothly.
Note that I only ever promote milestone builds (I think some promote
their integration builds, too).
Nick? Any idea why my component's contribution would disappear
without me doing anything?
Thanks,
Christian
On 18-Feb-09, at 6:14 AM, Galileo buildmaster [Richard Gronback] wrote:
Contribution org.eclipse.emf.emfqtv.all.sdk version
1.3.0.v200901271819-4778Z90GCMMEHd_ETTaTWy4q7vXc failed to install
from http://download.eclipse.org/modeling/emf/updates/milestones/.
Check the log file for more information:
http://build.eclipse.org/galileo/build/galileo-I20090218-0609.log.txt
.
--
Nick Boldt :: http://wiki.eclipse.org/User:Nickb
Release Engineer :: Eclipse Modeling & Dash CBI
