Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-ocl.dev] Kepler/Luna releases
Hi Ed,

Comments in-lined below:

On Sun, Aug 18, 2013 at 12:37 PM, Ed Willink <ed@xxxxxxxxxxxxx> wrote:
Hi

I think the (temporary) release branch has a number of advantages

a) changes from master cannot squeeze in after releng starts.
b) auto-builds will not happen for master during release
c) releng commits can be reverted, so that the eventual merge to master can be compressed to what worked, free from typos and other stupidities

 Ok.

If the 'a' builds are not often required we can go for the target name directly.

My doubt is if we should do it every milestone. In practice I guess it´s not needed. We wouldn´t be doing an strict S-build using ther ir S-repo, but the result of doing so would be pretty the same.

To be more precise, we need to "do it" to verify final downstream contributions, but we don´t necessarily need "to publish it".

So:
- If last minute change introduced by our +2 projects breaks our contribution at compile time, the aggregator (and our nightly build) will notice us and we would havel to fix the issue and run and publish a new S-build ("a" one)
- To detect harnful functionality changes produced by our +2 projects contribution, we could still need to run a "testing S-build". If test cases pass, we simply delete it (we don´t need to publish), if test cases fail we need to fix the problem and run and publish a new S-build (a).

We could also configure job-tests to also be able to run S-builds, so we don´t need to delete the "testing S-build" (We could forget to do it, and it could be automatically published during the night).

Does this make sense ?

Improved workflow:

a) Fast-forward merge the 'release' branch with 'master'
b) Switch the (only one needed) job configuration to 'release'
c) Build x.y.z.Mn at +1 allowing N/I repo contributions (RESOLVE_N4S = true)
d) Build x.y.z.Mna at +3 using only S repo contributions (RESOLVE_N4S = false,. the default)
if practice 'a' build reuses all old features and plugins, no 'a' build needed
if practice 'a' build creates a newer feature or plugin, do a real 'a' build
I don´t understand this. I think that the only judgement we can have to see if the need to do an publish a real build, is building a tentative/practive build and check if it pass/fails.
 
e) Switch the job configuration back to 'master'

The RESOLVE_N4S parameter was really easy to do and avoids impact on the publishing scripts, download pages, other places that I don't know about.

As commented, I´m happy if you prefer this. 

Regards,
Adolfo.

    Regards

        Ed




On 17/08/2013 17:27, Adolfo Sánchez-Barbudo Herrera wrote:

"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).

I didn´t like that solution, because you have a global parameter which only makes sense when an specific value of another parameter is selected. In any case, if you prefer that rather than reviewing the publishing scripts, it´s fine to me.
 
---

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?

I can´t help too much here. This comes from doing what other relengs did when I started to work on buckminster. In practice, I don´t benefit from it, but yes it´s a property supposed to be changed when working in local if you wanted to avoid downloading a new target platform every time you do configuration tests in local. Since in hudson, workspace and target platform are cleaned prior to build, the TP always need to be downloaded.


----

Anyway our eventual workflow could be

Fast-forward merge the 'release' branch with 'master'

First time I heard of a "release" branch in this context.


+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.)

We are officially a +1 project, so in my opinion we do need a 4.2.0M1 build at M1+1. Having something different will confuse users rather than help. Instead, I´d use the traditional convetion of using the "a" suffix to use at M1+3.


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.

Delayed contribution to release train makes sense to me. We´d still have a proper milestone repository to which downstream projects should build against.

+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.

As commented, I´d produce a 4.2.0M1a. We could even build at +2 once our +2 dependencies are in place. The old dicussion of requesting to be a +2 project can be taken up, if accepted we would avoid having to create a 4.2.0Mxa every milestone.


If the +3 build fails, fixes/workarounds are developed in the 'release' branch. Once successful, 'release' and 'master' are merged.


I´m not sure we need a release branch, just fixes on the master (which should be only produced by last minute +2 projects).

Regards,
Adolfo.


_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3392 / Virus Database: 3211/6585 - Release Date: 08/17/13



_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev


Back to the top