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.
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@fedoraproject.org Fedora Project Leader _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
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.
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@fedoraproject.org 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@fedoraproject.org Fedora Project Leader _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
I do like the idea. I think three target dates make sense.
2017-11-09 10:49 GMT+01:00 Jan Kurik jkurik@redhat.com:
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@fedoraproject.org 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@fedoraproject.org Fedora Project Leader _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Thu, Nov 9, 2017 at 10:49 AM, Jan Kurik jkurik@redhat.com 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@fedoraproject.org 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@fedoraproject.org Fedora Project Leader _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
-- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
On 3 November 2017 at 05:55, Matthew Miller mattdm@fedoraproject.org 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.
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 testingperiod, 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". :)
On Tue, Nov 14, 2017 at 5:17 PM, Matthew Miller mattdm@fedoraproject.org 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 testingperiod, 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@fedoraproject.org Fedora Project Leader _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
-
Jan Kurik -
John Florian -
Matthew Miller -
Nick Coghlan -
Silvia Sánchez