[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-ocl.dev] Kepler/Luna releases
|
Hi Adolfo
On 15/08/2013 13:00, Adolfo Sanchez-Barbudo Herrera wrote:
In principle I had in mind, one build, a similar configuration which
we have for the branch-tests, but some work is needed for the parts
that branch-tests doesn't do (basically the publishing part). However,
I understand from what you say, that indeed we still need to make some
distinction between a +1 build and a +3 one, to feed the build with
different repositories (I/S -even N- repositories at +1 and just S
repositories at +3).
I guess that just a new build.type option (S1 and S3 replacing S)
could work for us, but you would need to carefully revise of the
publishing part (that build.type usage).
In any case, I would plan any transition after M1 to avoid stress. For
SR1 RCs may be it's not even worthy to do it.
We have the option of just reverting all progress on Monday morning.
Fortunately nearly all the functionality is there, just partitioned in
three variants.
When merging I got a clue as to why the examples fails on branch tests;
there seems to be an inconsistent LPG dependency that could cause a
failure at exactly the right point.
------
I wasn't sure about your built.type suggestion, since I thought it was
built-in, but it seems to be our choice. Except that it isn't. For
instance the download page categorises by first letter.
"S1" and "S3" have a leading digit and so confuse slightly in S32013.....
"IS" and "S" need revision of the promotion scripts and IS doesn't start
with S
"SI" and "S" has a leading letter that looks like a number
"T" and "S" introduces a new letter that wont work on the download pages
"S" and "S" is much better; all the downstream stuff just sees pairs of
Ses with slightly different dates. No real problem.
Anyone using the milestones repo just sees a new build appear.
We just need to add a Boolean build parameter RESOLVE_I4S so that the
rmap resolution filter allows I repos when doing an S-build (for all
dependencies other than platform and EMF).
---
Side issue: what is "resolve.target.platform" for? It seems to always be
true. Is it for some private testing config that I don't understand?
----
Anyway our eventual workflow could be
Fast-forward merge the 'release' branch with 'master'
+1 build ('Core')
Do an S build from 'release', without alias, with RESOLVE_I4S true.
Promotion populates the .../milestones repo (not .../milestones/core).
Aggregator picks it up from milestones.
(Download pages and repos will therefore show this build as S2013....
so users hopefully not be confused with the true 4.2.0M1 build.)
If the +1 build fails in the aggregator, we will have to choose between
delaying contribution until our dependency has contributed, or finding
some temporary workaround.
+3 build ('Tools')
Do an S build from 'release', with alias such as 4.2.0M1, with
RESOLVE_I4S false. Promotion populates the .../milestones repo (not
.../milestones/tools). Aggregator picks it up from milestones.
If the +3 build fails, fixes/workarounds are developed in the 'release'
branch. Once successful, 'release' and 'master' are merged.
----
Failures, other than Hudson eccentricities, may be
Compilation failure: a dependency has made an API change between their I
and S. We can grumble, but in the short timescale we will probably have
to workaround.
Test failure: a dependency has made a functional change between their I
and S. We can grumble, but in the short timescale we will probably have
to workaround.
Hidden failure 1: a dependency has made a functional change between
their I and S that causes our code to malfunction in ways that are not
detected by our tests. Tough; that's why we have milestones to doscover
these problems.
Hidden failure 2: a dependency has made a functional change between
their I and S that causes dependent code to malfunction. Tough; not
really our problem.
Regards
Ed Willink
