Re: [eclipse.org-planning-council] Simultaneous Release Brainstorming

[Frederic Gurr <frederic.gurr@xxxxxxxxxxxxxxxxxxxxxx>]

Hi,

On 07.03.2018 09:22, Mélanie Bats wrote:
> Hi,
> 
> 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
> packages.

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

>> 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?

Regards,

Fred

-- 
Frederic Gurr

Release Engineer
Eclipse Foundation