Changes Policy & Fedora Release Life Cycle - request for review

[Jan Kurik]

Hi everybody,

I tried to merge together all the changes we were facing during the
last time with regards to Changes Policy & Fedora Release Life Cycle.
The outcome is available in [1] and [2]. Before I will ask FESCo for a
review, I would like to ask anyone who is interested for a review and
comments.

Basically the changes I did are related to the following topics:
* No More Alphas Change [3]
* Discussion about String Freeze [4]
* Rain dates and such [5]
* Removal of description how to build schedule on your own as this
paragraph was not already valid. I might add some description of this
later, however I do not think that this belongs to Life Cycle policy
anyway.

[1] https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle
[2] https://fedoraproject.org/wiki/User:Jkurik/Changes.Policy
[3] https://fedoraproject.org/wiki/Changes/NoMoreAlpha
[4] https://lists.fedoraproject.org/archives/list/[e-mail]/...
[5] https://lists.fedoraproject.org/archives/list/[e-mail]/...

Thanks,
Jan

[Matthew Miller]

On Fri, Nov 10, 2017 at 05:27:25PM +0100, Jan Kurik wrote:
> [1] https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle

This looks generally good to me. The one change I would make is to
add to "Tue: Primary date from which rest of schedule derives". Make
that:

Tue: Primary date from which rest of schedule derives

This date is either the Tuesday before May 1st or October 31st.

Upcoming potential target dates are: 2018-04-24, 2018-10-30,
   2019-04-30, and 2019-10-29.

Can you draw up how exactly any changes would affect:

https://fedoraproject.org/wiki/Releases/28/Schedule (FESCo approved)
https://fedoraproject.org/wiki/Releases/29/Schedule (still a draft)

I think offhand that they're basically the same (and that this change
basically brings the policy in line with the praxis), but I may have
missed something.

On a bigger note: Do we really want to have a window after branch where
Bodhi isn't active? Might it be better to put that as part of the
Branch step? I don't think we want a longer freeze period (especially
during beta) but we

And, on a even bigger note, the F27 July-to-October experiment worked
reasonably well (with the large remainer of the still-outstanding
Modular Server) but I don't think we want to do that again. I'd like to
suggest that if the April/May release slips into July, or the
October/November release slips into January, we *automatically* skip
the next target date for a _longer_ cycle to bring us back to schedule
rather than a short one.

[Michael Catanzaro]

On Fri, Nov 10, 2017 at 11:18 AM, Matthew Miller 
 wrote:
> And, on a even bigger note, the F27 July-to-October experiment worked 
> reasonably well (with the large remainer of the still-outstanding 
> Modular Server) but I don't think we want to do that again. I'd like 
> to suggest that if the April/May release slips into July, or the 
> October/November release slips into January, we *automatically* skip 
> the next target date for a _longer_ cycle to bring us back to 
> schedule rather than a short one.

I thought it worked quite well. If a release gets delayed to July and 
we completely skip the October release, so that the next release is in 
April/May, then we need to be willing to push out major version 
upgrades to the current stable release, and accept any accompanying 
breakage. And that really blows up the entire concept of having stable 
releases. A 10 month release cycle seems like a much bigger change to 
me than a four month cycle. Fedora can't be a year behind and remain 
relevant.

Michael

[Kevin Fenzi]

On 11/10/2017 09:18 AM, Matthew Miller wrote:
...snip...
> On a bigger note: Do we really want to have a window after branch where
> Bodhi isn't active? Might it be better to put that as part of the
> Branch step? I don't think we want a longer freeze period (especially
> during beta) but we

You got cut off there?

The reason in the past for the window after branching, but before bodhi
enablement was because it allowed for a small window to fix up fallout
from branching, but if everyone is ok with just doing it at the same
time I suppose it should be possible.
> And, on a even bigger note, the F27 July-to-October experiment worked
> reasonably well (with the large remainer of the still-outstanding
> Modular Server) but I don't think we want to do that again. I'd like to
> suggest that if the April/May release slips into July, or the
> October/November release slips into January, we *automatically* skip
> the next target date for a _longer_ cycle to bring us back to schedule
> rather than a short one.

Sounds somewhat reasonable, but might get us behind on 'first'

kevin

[Vít Ondruch]

Dne 10.11.2017 v 18:18 Matthew Miller napsal(a):
> On Fri, Nov 10, 2017 at 05:27:25PM +0100, Jan Kurik wrote:
> > [1] https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle
>
> Do we really want to have a window after branch where
> Bodhi isn't active?

Bit of OT, but I'd appreciate if Bodhi was enabled even for Rawhide ;)

(Sorry, couldn't help myself)
> And, on a even bigger note, the F27 July-to-October experiment worked
> reasonably well (with the large remainer of the still-outstanding
> Modular Server) but I don't think we want to do that again. I'd like to
> suggest that if the April/May release slips into July, or the
> October/November release slips into January, we *automatically* skip
> the next target date for a _longer_ cycle to bring us back to schedule
> rather than a short one.

I like this idea.

V.

[Jan Kurik]

On Fri, Nov 10, 2017 at 6:18 PM, Matthew Miller
 wrote:
> On Fri, Nov 10, 2017 at 05:27:25PM +0100, Jan Kurik wrote:
> > [1] https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle
>
> This looks generally good to me. The one change I would make is to
> add to "Tue: Primary date from which rest of schedule derives". Make
> that:
>
> Tue: Primary date from which rest of schedule derives
>
> This date is either the Tuesday before May 1st or October 31st.
>
> Upcoming potential target dates are: 2018-04-24, 2018-10-30,
>    2019-04-30, and 2019-10-29.

I added the "This date is either the Tuesday before May 1st or October
31st." sentence which makes sense to me. However I would not be happy
to add exact dates in a policy. A policy should be a general document.
Having exact dates can make it obsolete in case of any action we might
take in a future with a schedule for a particular release.
> Can you draw up how exactly any changes would affect:
>
> https://fedoraproject.org/wiki/Releases/28/Schedule (FESCo approved)
> https://fedoraproject.org/wiki/Releases/29/Schedule (still a draft)
>
> I think offhand that they're basically the same (and that this change
> basically brings the policy in line with the praxis), but I may have
> missed something.

There should be no major changes in the 28 and 29 schedules. Except
naming of some milestones (replacement of the Rain date) the only
milestone which is going to change is "String freeze".
> On a bigger note: Do we really want to have a window after branch where
> Bodhi isn't active? Might it be better to put that as part of the
> Branch step? I don't think we want a longer freeze period (especially
> during beta) but we

I am adding Mohan (release engineering) on CC to answer this question.
> And, on a even bigger note, the F27 July-to-October experiment worked
> reasonably well (with the large remainer of the still-outstanding
> Modular Server) but I don't think we want to do that again. I'd like to
> suggest that if the April/May release slips into July, or the
> October/November release slips into January, we *automatically* skip
> the next target date for a _longer_ cycle to bring us back to schedule
> rather than a short one.

In my opinion, having a shorter cycle is better option than completely
skip one release. A shorter cycle puts us under stress, but we still
have things under control. Skipping a release might have many
consequences we might not even think of, like issues with branching
etc. I would be quite conservative here.

Jan
> --
> Matthew Miller
>
> Fedora Project Leader
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Mohan Boddu]

I dont want to reduce the time between branching and bodhi enablement. The gap is for any short comings from branching, but if you guys think it is absolutely necessary then I am okay with reducing it to a week.

Also, I want to point out that traditionally Alpha freeze and Bodhi enablement will happen on the same day. With no alpha from F27 I think Bodhi enablement should happen along with Beta Freeze. Probably that will help in reducing the timeline. https://pagure.io/fesco/issue/1792

[Adam Williamson]

On Fri, 2017-11-10 at 17:27 +0100, Jan Kurik wrote:
> Hi everybody,
>
> I tried to merge together all the changes we were facing during the
> last time with regards to Changes Policy & Fedora Release Life Cycle.
> The outcome is available in [1] and [2]. Before I will ask FESCo for a
> review, I would like to ask anyone who is interested for a review and
> comments.

It would be much easier to review if we could see a diff to the current
contents of the pages. When doing drafts like this, I usually copy the
original page *without* changes first, *then* make my changes, so the
'history' tab can be used to view the changes from the original
content.

[Adam Williamson]

On Tue, 2017-11-14 at 10:41 -0800, Adam Williamson wrote:
> On Fri, 2017-11-10 at 17:27 +0100, Jan Kurik wrote:
> > Hi everybody,
> >
> > I tried to merge together all the changes we were facing during the
> > last time with regards to Changes Policy & Fedora Release Life Cycle.
> > The outcome is available in [1] and [2]. Before I will ask FESCo for a
> > review, I would like to ask anyone who is interested for a review and
> > comments.
>
> It would be much easier to review if we could see a diff to the current
> contents of the pages. When doing drafts like this, I usually copy the
> original page *without* changes first, *then* make my changes, so the
> 'history' tab can be used to view the changes from the original
> content.

I realized I could just do this for you, so I did:

https://fedoraproject.org/wiki/User:Jkurik/Changes.Policy.diff
https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle.diff

For both pages, I first created them with the current content of the
original pages, then edited them to contain the same content as your
most recent drafts. So on the history tab, you can easily diff the
proposed changes.

[Tim Landscheidt]

Adam Williamson  wrote:
> > I tried to merge together all the changes we were facing during the
> > last time with regards to Changes Policy & Fedora Release Life Cycle.
> > The outcome is available in [1] and [2]. Before I will ask FESCo for a
> > review, I would like to ask anyone who is interested for a review and
> > comments.
> It would be much easier to review if we could see a diff to the current
> contents of the pages. When doing drafts like this, I usually copy the
> original page *without* changes first, *then* make my changes, so the
> 'history' tab can be used to view the changes from the original
> content.

In MediaWiki, revisions compared in a diff do not need to
belong to the same article.  So for example, to compare the
current revision of
https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle
(488139) to the current revision of
https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle
(505754), you can use the URL
https://fedoraproject.org/w/index.php?diff=505754&oldid=488139.
This is not as convenient (or obvious :-)) as your approach,
but it does not depend on a) somebody copying the original
first and b) not making a mistake when copying & pasting.

Tim

[Przemek Klosowski]

On 11/14/2017 07:47 PM, Tim Landscheidt wrote:
> In MediaWiki, revisions compared in a diff do not need to
> belong to the same article.  So for example, to compare the
> current revision of...(488139) to the current revision of
> ...(505754), you can use the URL
> https://fedoraproject.org/w/index.php?diff=505754&oldid=488139
> This is not as convenient (or obvious :-)) as your approach,

Is there a way to click into that, or do you just know the URL and 
substituted the IDs by hand? How did you get the IDs of the two pages in 
the first place?

[Tim Landscheidt]

Przemek Klosowski  wrote:
> In MediaWiki, revisions compared in a diff do not need to
> belong to the same article.  So for example, to compare the
> current revision of...(488139) to the current revision of
> ...(505754), you can use the URL
> https://fedoraproject.org/w/index.php?diff=505754&oldid=488139
> This is not as convenient (or obvious :-)) as your approach,
> Is there a way to click into that, or do you just know the URL and substituted the IDs by hand? How did you get the IDs of the two pages in the first place?

This kind of URL is not exposed by the UI (AFAIAA).  I as-
sembled the URL by:

1. Going to
   https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle,
   "history", "Compare selected revisions" which gives
   https://fedoraproject.org/w/index.php?title=Fedora_Release_Life_Cycle&di...
   (which means 488140 is the current revision (on the right
   side of the diff)),

2. doing the same for
   https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle
   which gives
   https://fedoraproject.org/w/index.php?title=User%3AJkurik%2FFedora_Release_L...,
   and

3. assembling the URL by removing the "title" parameter
   (just for cosmetics), setting the "oldid" parameter to
   the revision to appear on the left side and the "diff"
   parameter to the revision to appear on the right side.

(Cf. https://www.mediawiki.org/wiki/Manual:Parameters_to_index.php#View_and_rende...
for documentation.)

Tim

[Adam Williamson]

On Wed, 2017-11-15 at 00:47 +0000, Tim Landscheidt wrote:
> Adam Williamson  wrote:
> > > I tried to merge together all the changes we were facing during the
> > > last time with regards to Changes Policy & Fedora Release Life Cycle.
> > > The outcome is available in [1] and [2]. Before I will ask FESCo for a
> > > review, I would like to ask anyone who is interested for a review and
> > > comments.
> >
> > It would be much easier to review if we could see a diff to the current
> > contents of the pages. When doing drafts like this, I usually copy the
> > original page *without* changes first, *then* make my changes, so the
> > 'history' tab can be used to view the changes from the original
> > content.
>
> In MediaWiki, revisions compared in a diff do not need to
> belong to the same article.  So for example, to compare the
> current revision of
> https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle
> (488139) to the current revision of
> https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle
> (505754), you can use the URL
> https://fedoraproject.org/w/index.php?diff=505754&oldid=488139.
> This is not as convenient (or obvious :-)) as your approach,
> but it does not depend on a) somebody copying the original
> first and b) not making a mistake when copying & pasting.

Oooh, handy. I never knew that. Thanks.

[Adam Williamson]

On Fri, 2017-11-10 at 17:27 +0100, Jan Kurik wrote:
> Hi everybody,
>
> I tried to merge together all the changes we were facing during the
> last time with regards to Changes Policy & Fedora Release Life Cycle.
> The outcome is available in [1] and [2]. Before I will ask FESCo for a
> review, I would like to ask anyone who is interested for a review and
> comments.
>
> Basically the changes I did are related to the following topics:
> No More Alphas Change [3]
> Discussion about String Freeze [4]
> Rain dates and such [5]
> Removal of description how to build schedule on your own as this
>
> paragraph was not already valid. I might add some description of this
> later, however I do not think that this belongs to Life Cycle policy
> anyway.

Changes look fine to me, having looked at them quickly. There's a few
very minor changes from my Fedora Release Life Cycle draft which don't
seem to be in yours, but nothing too important; I can just wait until
you changes are made then check if any of mine are still needed.
Thanks.