|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 beCompilation 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
Back to the top