Bug 356644

Comment 1 Kenn Hussey 2011-09-08 09:12:57 EDT

So... any chance this could be sorted out in time for next week's M2 build? If so, it would be good if an integration build were made available before that so that we can verify that the problem is solved.

Comment 2 John Arthorne 2011-09-09 08:51:04 EDT

We will run a test build as soon as possible. We have had a crazy build week with last minute 3.7.1/4.1.1 respins added to our 3.8/4.2 milestone warmup builds. The best option for us would be to enable this immediately after M2 so we have some time to make sure things are running smoothly before putting into a milestone.

Comment 3 John Arthorne 2011-09-09 08:57:07 EDT

Created attachment 203053 [details]
Patch to e4 rcp feature

Comment 4 Andrew Niefer 2011-09-13 10:34:15 EDT

Created attachment 203250 [details]
initial changes to releng builder

Comment 5 John Arthorne 2011-09-13 11:30:46 EDT

Kenn, we were currently fetching EMF content from the /emf/updates/2.7milestones repository. There doesn't seem to be a corresponding 2.8milestones repository yet. Do you have plans to set that up? Basically we need a repository where we can grab the latest EMF in our build and be sure it is a stable version. Andrew's patch uses the 2.8-I-builds site but this doesn't seem right. We can't be sure that the latest I-build is a good one at any given moment we need to run a Platform build.

Thinking more about this, I don't think it solves our cyclic build-time dependency. When Platform delivers a milestone, we will want the milestone release of EMF included in it, even though we specify a range that allows the EMF to be replaced with a different version if desired. This is especially important at release time, since if we don't include the official release of EMF we will be distributing unreleased EMF content.

We'll still go ahead with the change because it helps with the problem of users/products being able to install and depend on newer versions of EMF from the one shipped with the platform. I just want to be clear that we will still need to build Platform 4.x after the EMF core features are available.

Comment 6 Kenn Hussey 2011-09-13 11:37:46 EDT

(In reply to comment #5)
> Kenn, we were currently fetching EMF content from the
> /emf/updates/2.7milestones repository. There doesn't seem to be a corresponding
> 2.8milestones repository yet. Do you have plans to set that up? Basically we
> need a repository where we can grab the latest EMF in our build and be sure it
> is a stable version. Andrew's patch uses the 2.8-I-builds site but this doesn't
> seem right. We can't be sure that the latest I-build is a good one at any given
> moment we need to run a Platform build.

Yes, the 2.8milestones repo will be in place for M2. This Friday for base and Monday for core.

> Thinking more about this, I don't think it solves our cyclic build-time
> dependency. When Platform delivers a milestone, we will want the milestone
> release of EMF included in it, even though we specify a range that allows the
> EMF to be replaced with a different version if desired. This is especially
> important at release time, since if we don't include the official release of
> EMF we will be distributing unreleased EMF content.

This shouldn't be a problem in practice since base EMF has few dependencies on the Platform and building against the previous milestone won't be the end of the world. We can build early on +0 day for you to pick it up...

> We'll still go ahead with the change because it helps with the problem of
> users/products being able to install and depend on newer versions of EMF from
> the one shipped with the platform. I just want to be clear that we will still
> need to build Platform 4.x after the EMF core features are available.

OK, we can try to coordinate for the release build (e.g., freeze EMF an RC cycle earlier or make the final base build available early on the final +0 day).

Comment 7 John Arthorne 2011-10-04 16:37:00 EDT

This change has been released. Verified in I20110930-1625.