Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] Simultaneous Release Brainstorming

When we talk about "an EPP build" we mean one that's "announced" or "declared", rather than the continuous integration (CI) builds [1] that happen all the time, right?


My point is that as we move to a model of more frequent, continuous releases, anyone and everyone can test/use/enjoy the CI builds at any time, rather than having to wait 6 weeks for a "declared" released. (That's what I've been doing for the last couple of months to get WTP ready for Photon.0.M6, using platform I-builds and EPP CI builds.)



On Wed, Mar 7, 2018 at 9:03 AM, Mélanie Bats <melanie.bats@xxxxxxx> wrote:

Le 07/03/2018 à 12:42, Frederic Gurr a écrit :
Le 06/03/2018 à 19:56, Frederic Gurr a écrit :
Can someone remind me what the purpose of the second checkpoint (C2) is?
Why is it not a milestone instead?

The purpose of the second checkpoint was to provide a step to
synchronize the projects without the test phase, we will not build EPP

With the old cadence, Oxygen Release and it's update releases had/have:
- 7 Milestones (M1-M7 for GA)
- 16 Release Candidates
   - 4 RCs for GA
   - 4 RCs for .1, .2, .3 (the first one is a warm-up, so no EPP build)
- another 2 RCs per JDK update (.1a, .3a)

=> 20 EPP builds (24 with RCs for JDK updates)

With the new cadence, a full cycle (YYYY.06, YYYY.09, YYYY.12, YYYY.03)
will have:
- 8 Checkpoints (2 per release, no EPP build)
- 4 Milestones (1 per release)
- 8 RCs (2 per release)

=> 12 EPP builds

If we'd replace the second checkpoint with a milestone, the total EPP
builds would increase to 16, which is still 4 less than before.

I'd recommend to do more testing, not (a lot) less. ;)

My thinking was for one cycle :
* with the old cadence : it was 1 EPP build almost every 6-7 weeks for milestones + 4 EPP build every week for RCs.
* with the new cadence it would be :
 * 1 milestone : 1 EPP build for milestone every 6 weeks + 2 EPP build every weeks for RCS. Mostly the same cadence than before for EPP build and testers.
 * 2 milestones : 1 EPP Build for milestones every 3-6 weeks + 2 EPP build every weeks for RCS. My point is that it means that we should build in this case EPP every 3 weeks which is not the same cadence for the EPP testers?

That's why I proposed 2 checkpoints instead of 2 milestones. But if every one is okay with 2 milestones no problem to change the proposed plan!

I'm a bit concerned about the "quiet week" becoming just "quiet 3 days".
It usually takes already 1-2 days to even fix a bug/discuss if a re-spin
should happen.
In this scenario re-spins will need to be an absolute exception - which
they should be anyways. So if the bug does not literally set the machine
on fire, user will need to wait for 13 weeks! ;)

 From my point of view, in this case we will discuss and
delayed/reschedule an intermediate release.
And as you said that should be an absolute exception.

How do we deal/align with extra builds for JDK updates?

For me, we just integrate this in our classical schedule and we do not have extra builds?
JDKs are released at the end of the month around the March 20 for JDK 10 for instance. As an example according to our plan we should have a release on March 20 2019, so it should mostly fit. If not we could review our plan to align them, else we could provide extra builds or wait for the next cycle.

Mélanie Bats
+33 7 87 69 42 84
+33 5 34 57 16 29

25 Boulevard Victor Hugo - Colomiers - France
_______________________________________________ mailing list

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.


Nick Boldt

Senior Software Engineer, RHCSA

Productization Lead :: JBoss Tools & Dev Studio

IM: @nickboldt / @nboldt /

“The Only Thing That Is Constant Is Change” - Heraclitus

Back to the top