> * What would be the planning ?> A proposed planning could be:> - M1 Friday Week 2> - M2 Friday Week 4> - M3 Friday Week 6> - M4 Friday Week 8> - RC1 Friday Week 9> - RC2 Friday Week 10> - Quiet week Week 11, it is assumed all code is done by the end of RC2.> - GA Wednesday Week 12
How about something simpler, with fewer delivery / alignment / integration checkpoints?
- C1 end of week 3 (checkpoint / integration build)
- M1 end of week 6
- C2 end of week 9 (second checkpoint)
(RCs as needed)
- RCn end of week 12
- quiet period & GA release end of week 13
So for projects that want to do weekly RCs, they can (between week 9 and 12) and for those who don't, their GA contribution will be RC1 in week 12.
The reason I propose this 3-week sprint cadence instead of the mixed 2- and 3- week plan suggested on the PC call today is that in my experience, developers and managers have a tendency to lose track of when upcoming release dates occur... but by making them land consistently every 3 weeks, you have time for sprint planning, execution, and release/review, and things become more predictable. And 3 weeks is a good length of time to see progress since a previous milestone, so users are more likely to install the update than a 2-week update. I would bet if you do biweekly releases, users will update about once a month (skipping every other release).
To address the concern about there being insufficient time for testing between RCx (week 12) and GA (week 13), we need to ensure that more of the manual tests done today are automated and can therefore be run on every CI and simrel integration. Admittedly easier said that done, but that ought to be a prioritized goal for the new simrel, since with greater speed we NEED greater testing. I'm willing to pitch in to help with that, once I'm done breaking WTP, DTP, and RSE. :)
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.