Jiří Konečný posted a request on the devel list a few weeks ago—he wanted to require a successful compose before the release is branched from Rawhide. As often happens, it’s not as simple as it seems on the surface, and the discussion eventually came around to not branching right after Flock.
This, too, isn’t as simple as it might seem. Changing one milestone in the schedule has impacts on the remaining milestones. We can make changes, of course, but we want to make sure we’re aware of the potential side effects. After discussing this with Mohan Boddu of the release engineering team, I have a few possible alternatives.
Before I present the alternatives, I want to cover a few of the considerations that went into this. The first is that Flock itself is not a predictable part of the schedule. Although it’s generally in early August, it bounces around a bit. This means it’s hard to predict ahead of time what the impact will be on the schedule.
Option 0: Do nothing
Option 0 is the baseline. It keeps the schedule the way it is. If the release engineers are jetlagged after Flock, they still have work to do. It’s worth noting here that in alternate years, the release engineering team won’t be traveling as far, so option 0 may be fine half the time.
Option 1: Delay branching
Option 1 delays the branching by a week, while keeping all other milestones in place. This shortens the time between branching and Bodhi activation/Beta freeze from two weeks to one. This is the simplest change from a schedule standpoint, but it only gives maintainers a week to test things in branched before the freeze kicks in.
Option 2: Delay branching, shorten beta freeze
Option 2 also delays branching by a week, but keeps the branch-to-Bodhi-activation window at two weeks. Thus the Beta freeze is shortened from three weeks to two. This gives maintainers the two week window to finish changes in branched, but shortens the amount of time available for testing. Mohan attributes the improved on-time delivery in the last few releases to the longer Beta freeze. Shortening this may result in unplanned changes to the schedule.
Option 3: Delay branching, delay beta release
Option 3 continues the pattern of delaying the branching by a week. Instead of shortening the Beta freeze, it pushes the freeze back a week, too. This shortens the time from Beta to Final by a week—from five weeks to four. It also means that the time from the Beta release to the beginning of Final freeze is two weeks if we release on the preferred target, one week if we release on Beta target #1. If the Beta release slips beyond target date #1, we immediately go into Final freeze or we delay the Final release.
Option 4: Delay everything
Option 4 adds a week to everything from the branch point and beyond. I include it here for completeness, although I strongly oppose it. The first reason I oppose it is marketing-related. With this option, the Final target date #1 milestone may end up in November. While it is still a week after the preferred target date, moving from October to November has a perceived difference. The second reason is that it pushes the elections further into December, so additional slips could mean the voting period ends up colliding with the end-of-year holidays.
Options 0-4 summarized
Here’s what the Fedora 31 schedule would look like under the various options.
|Milestone||Option 0||Option 1||Option 2||Option 3||Option 4|
|Flock||08–11 Aug||08–11 Aug||08–11 Aug||08–11 Aug||08–11 Aug|
|Change completion deadline (testable)||13 Aug||20 Aug||20 Aug||20 Aug||20 Aug|
|Branch||13 Aug||20 Aug||20 Aug||20 Aug||20 Aug|
|Bodhi activation||27 Aug||27 Aug||3 Sep||3 Sep||3 Sep|
|Change 100% code complete deadline||27 Aug||27 Aug||3 Sep||3 Sep||3 Sep|
|Beta Freeze starts||27 Aug||27 Aug||3 Sep||3 Sep||3 Sep|
|Beta preferred target date||17 Sep||17 Sep||17 Sep||24 Sep||24 Sep|
|Final freeze starts||8 Oct||8 Oct||8 Oct||8 Oct||15 Oct|
|Final preferred target||22 Oct||22 Oct||22 Oct||22 Oct||29 Oct|
|Final target #1||29 Oct||29 Oct||29 Oct||29 Oct||5 Nov|
Okay, this is a schedule alternative, but not a Schedule™ alternative. One option would be to say the week before the branch is off-limits for Flock. Of course, this could mean holding Flock later in the schedule where it might negatively impact feature finalization or testing instead of branching and composing. It might also make it more difficult to find a venue at an appropriate price. But it is a choice.
Make composes better
I know the release engineering team is working on this independently of whatever schedule changes we may make. In an ideal world, composes would always work. As Kevin Fenzi noted, Rawhide gating should help catch many of the issues.
Freeze right after branching
Several people suggested a variation of doing a brief freeze after branching until a successful compose completes. This could be one day or several, depending, but the freeze would end as soon as the compose is available.
I’m inclined to go with option 0, plus a brief freeze after branch. The Flock dates are variable and so it’s difficult to pre-plan around them. With Rawhide gating and a freeze in place, we should be less likely to see a repeat of this. In addition, while this is a regular problem, both Jiŕi and Kevin said this was an abnormally-long version of it. I’m hesitant to make a structural change in the schedule to accommodate an anomaly that will be mitigated by other means.
Editor’s note: comments are disabled on this post. Please use the devel list thread for discussion.