Minor schedule procedure tweak (rain dates and such)

[Matthew Miller]

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.


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[John Florian]

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:
> 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.
> 
> 
> -- 
> Matthew Miller
> <mattdm(a)fedoraproject.org&gt;
> Fedora Project Leader
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org

[Matthew Miller]

On Thu, Nov 02, 2017 at 04:40:30PM -0400, John Florian wrote:
>  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!!!" 

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.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Jan Kurik]

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
<mattdm(a)fedoraproject.org&gt; wrote:
>  On Thu, Nov 02, 2017 at 04:40:30PM -0400, John Florian wrote:
> > 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!!!"
>
>
>  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.
>
>  --
>  Matthew Miller
>  <mattdm(a)fedoraproject.org&gt;
>  Fedora Project Leader
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org 


-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

[Silvia Sánchez]

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



2017-11-09 10:49 GMT+01:00 Jan Kurik <jkurik(a)redhat.com&gt;:

>  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
>  <mattdm(a)fedoraproject.org&gt; wrote:
>  > On Thu, Nov 02, 2017 at 04:40:30PM -0400, John Florian wrote:
>  >> 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!!!"
>  >
>  >
>  > 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.
>  >
>  > --
>  > Matthew Miller
>  > <mattdm(a)fedoraproject.org&gt;
>  > Fedora Project Leader
>  > _______________________________________________
>  > devel mailing list -- devel(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>
>
>
>  --
>  Jan Kuřík
>  Platform & Fedora Program Manager
>  Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>

[Jan Kurik]

On Thu, Nov 9, 2017 at 10:49 AM, Jan Kurik <jkurik(a)redhat.com&gt; wrote:
>  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. 
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] https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle
[2] https://fedoraproject.org/wiki/Changes/NoMoreAlpha

Jan

>  Does it makes sense ?
>
>  Jan
>
>  On Thu, Nov 2, 2017 at 10:06 PM, Matthew Miller
>  <mattdm(a)fedoraproject.org&gt; wrote:
> > On Thu, Nov 02, 2017 at 04:40:30PM -0400, John Florian wrote:
> >> 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!!!"
> >
> >
> > 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.
> >
> > --
> > Matthew Miller
> > <mattdm(a)fedoraproject.org&gt;
> > Fedora Project Leader
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>
>
>
>  --
>  Jan Kuřík
>  Platform & Fedora Program Manager
>  Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic 


-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

[Nick Coghlan]

On 3 November 2017 at 05:55, Matthew Miller <mattdm(a)fedoraproject.org&gt;
wrote:

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

-- 
Nick Coghlan   |   ncoghlan(a)gmail.com   |   Brisbane, Australia

[Matthew Miller]

On Tue, Nov 14, 2017 at 02:58:19PM +1000, Nick Coghlan 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 
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". :)


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Jan Kurik]

On Tue, Nov 14, 2017 at 5:17 PM, Matthew Miller
<mattdm(a)fedoraproject.org&gt; wrote:
>  On Tue, Nov 14, 2017 at 02:58:19PM +1000, Nick Coghlan 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
>
>  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". :) 
Thanks Nick, the idea is now implemented in the draft of the policy:
https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle

Jan

>  --
>  Matthew Miller
>  <mattdm(a)fedoraproject.org&gt;
>  Fedora Project Leader
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org 


-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic