| Re: [eclipse.org-planning-council] Simultaneous Release Brainstorming |
Hi,
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
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. ;)
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
CTO
+33 7 87 69 42 84
+33 5 34 57 16 29
@melaniebats
*Obeo*
25 Boulevard Victor Hugo - Colomiers - France
http://www.obeo.fr_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@eclipse.org
https://dev.eclipse.org/mailman/listinfo/eclipse.org-plannin g-council
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 / http://nick.divbyzero.com