DevHeads.net

Minor schedule procedure tweak (rain dates and such)

It turns out that the "Rain Date" concept is confusing to some people
(particularly where that idiom is not familiar). I propose that for F28
and onward, we keep the basic concept, but ditch that term. Instead, we
use:

* Release Date Target 1
* Release Date Target 2 (a week later).

As now, these will exist for both Beta and Final, and final will only
be pushed back if Beta Target 2 is missed.

Then (and also new), if the Beta does slip past Target 2, we add a new
"Target 3". If Beta slips to Target 3, Final slips to Target 2 (and we
don't yet add a Target 3). If beta slips to Target 4, we cross off
Final Target 2 and add Final Target 3.

I'm happy to bikeshed on calling "Target 1" something like "Early
Target". Langdon suggested just dropping any adjectives (hence just "1"
and "2", which works, but I want to balance between a feeling of "not
really important because it's a fake target" (bad!) and journalists
reporting "Fedora slipped once again, of course, because they're always
late", no matter how much we explain the process to them.

Comments

Re: Minor schedule procedure tweak (rain dates and such)

By Nick Coghlan at 11/14/2017 - 00:58

On 3 November 2017 at 05:55, Matthew Miller < ... at fedoraproject dot org>
wrote:

The mismatch in the numbering here feels inherently confusing to me.

How about if the numbers were aligned, and then the first Beta target date
was called something like "Preferred Beta Target" or "Beta Target 0"?

That would give:

* Beta Target 0 (preferred): missing this shortens the Beta testing
period, but doesn't necessarily cause the Final release to slip
* Beta Target 1: missing this means Final Target 2 is the earliest
release date that will be considered
* Beta Target 2: missing this means defining new Beta Target 3 and
Final Target 3 dates
* Final Target 1: releasing on this date requires hitting Beta Target 0
or Beta Target 1
* Final Target 2: fallback release target if Beta Target 1 and/or Final
Target 1 are missed

Regards,
Nick.

Re: Minor schedule procedure tweak (rain dates and such)

By Matthew Miller at 11/14/2017 - 12:17

On Tue, Nov 14, 2017 at 02:58:19PM +1000, Nick Coghlan wrote:
Sure, that works for me. I also appreciate your sneaking in the word
"preferred" there, because otherwise "Target 0" sounds like "We know
this'll never happen". :)

Re: Minor schedule procedure tweak (rain dates and such)

By Jan Kurik at 11/20/2017 - 20:51

On Tue, Nov 14, 2017 at 5:17 PM, Matthew Miller
< ... at fedoraproject dot org> wrote:
Thanks Nick, the idea is now implemented in the draft of the policy:
<a href="https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle" title="https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle">https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle</a>

Jan

Re: Minor schedule procedure tweak (rain dates and such)

By John Florian at 11/02/2017 - 16:40

Call me crazy, I don't mind, but what about scheduling the release
dates in reverse, using whatever naming scheme? Then as the release is
finalized, we either stick to the last release date if there were lots
of "slips" or we select an earlier release date because things went
really well. This might then be viewed as "Fedora released on time!"
or "Fedora released early!!!"

Full disclosure:
I'm left-handed so backwards things seem normal to me. :)

On Thu, 2017-11-02 at 15:55 -0400, Matthew Miller wrote:

Re: Minor schedule procedure tweak (rain dates and such)

By Matthew Miller at 11/02/2017 - 17:06

On Thu, Nov 02, 2017 at 04:40:30PM -0400, John Florian wrote:

Yeah, that's basically the idea, except only building in two target
dates in advance. If we have, like, six, I'm definitely sure no one
will take the first once seriously.

Re: Minor schedule procedure tweak (rain dates and such)

By Jan Kurik at 11/09/2017 - 05:49

We do not slip only on Beta or Final. In the past we had also some
troubles during Mass Rebuild which were causing slip of a whole
release. As I like the idea Matthew proposed I would like to expand
the "Slipping policy" with a rule:

If Mass Rebuild slips for a week the Beta release date moves to Beta
Target #2 and Final release date moves to Final Target #2 without
adding Target #3 date for Beta nor Final.

Does it makes sense ?

Jan

On Thu, Nov 2, 2017 at 10:06 PM, Matthew Miller
< ... at fedoraproject dot org> wrote:

Re: Minor schedule procedure tweak (rain dates and such)

By Jan Kurik at 11/09/2017 - 06:58

On Thu, Nov 9, 2017 at 10:49 AM, Jan Kurik < ... at redhat dot com> wrote:
I was thinking of it a bit more and the concept I proposed above
causes shrink of the period between Branching and Beta Freeze. As this
might be more complex I have tried to incorporate the concept into the
Release Live Cycle policy [1] I am preparing for FESCo to approve (to
finish the "No More Alphas" Change [2]). Basically my proposal for
Mass rebuild slips has changed to:

If Mass rebuild is not finished on time all the subsequent milestones
starting with Branch point are pushed back for one week until the Mass
rebuild is not finished.

What do you think ?

[1] <a href="https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle" title="https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle">https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle</a>
[2] <a href="https://fedoraproject.org/wiki/Changes/NoMoreAlpha" title="https://fedoraproject.org/wiki/Changes/NoMoreAlpha">https://fedoraproject.org/wiki/Changes/NoMoreAlpha</a>

Jan

Re: Minor schedule procedure tweak (rain dates and such)

By Sylvia at 11/09/2017 - 06:46

I do like the idea. I think three target dates make sense.

2017-11-09 10:49 GMT+01:00 Jan Kurik < ... at redhat dot com>: