RelEng ticket to remove Alha releases: #6621

If the remove-alpha proposal works out, I'm not sure just skipping the the Alpha dates is the best we can do. I'm we should move the branch as late as possible (to minimize the time spent branched and diverging), but also build in an additional week in additional week in Beta (because we usually slip) and give a pre-planned "alternate date" for the actual release (also because we always slip, but this way it looks more like we planned for it). Something like:

2017-02-28
Branch Fedora 26 from Rawhide (Rawhide becomes future F27)

2017-06-20
Fedora 26 Release

2017-06-20
Change Checkpoint: Proposal submission deadline (Changes requiring mass rebuild)

2017-07-04
Change Checkpoint: Proposal submission deadline (System Wide Changes)

2017-07-12
Mass Rebuild

2017-07-25
Change Checkpoint: Proposal submission deadline (Self Contained Changes)

2017-08-01
Branch Fedora 27 from Rawhide
Change Checkpoint: Completion deadline (testable)
Software String Freeze

2017-08-22
Software Translation Deadline

2017-08-29
Bodhi activation point
Beta Freeze
Change Checkpoint: 100% Code Complete Deadline

2017-09-12 (Target date)
Beta Release

2017-09-19 (Rain date)
Beta Release

2017-10-10
Final Freeze

2017-10-24
Fedora 27 Final Release (GA)  (Target date)

2017-10-31
Fedora 27 Final Release (GA) (Rain date!)

I moved the submission deadline for self-contained changes correspondingly up, but left the one for system changes at the same point, because having no alpha doesn't really make those any less complex. I'm not sure about "bodhi activation point" — the proposed Rawhide changes might make everything go through bodhi, right?

My intention to skip the Alpha dates applies just for F27. I wanted to have discussion about new milestones for Changes, Branching, etc. during the F27 period as part of "Alpha removal Change". The aim was to minimize ambiguity about the deadlines during the release cycle it self.
However, you are right that we can make some decisions here as part of this ticket and just reflect these in the "Alpha removal Change" proposal.

we should remove the (not planned) from the mass rebuild. it should always be planned and removed if not needed. as to removing alpha everything before it would gain 4 weeks on alpha removal

Yes, I agree. I think there is value in doing a mass rebuild even if there's no Change explicitly asking for one. Through doing one every cycle we ensure that the distro stays self-hosting (packages in FXX can be rebuilt using the toolchain that's in FXX) and we can more easily track which packages are failing to rebuild and when they started failing.

The boost maintainer had a lot of issues this cycle doing the boost rebase, because a lot of packages needing rebuilds were FTBFS without the maintainers being aware of it. This is likely partially due to us skipping a mass rebuild in F25.

Also, as I understand releng is planning on importing the s390x to primary koji for F27 and that is already one F27 Change that could use a mass rebuild to make sure all s390x packages are properly rebuilt on primary koji.

AGREED: jkurik's Fedora 27 schedule is approved with a removal of the "(not planned)' next to the rebuild (+1:6,0:0,-1:0)

Is this approved with the assumption that we will have an Alpha? Or, are we saying that we want to use all of that time for the mass rebuild and will not build in extra time for the Beta and Final?

In addition to all of the artifacts produced, Alpha provides a checkpoint where we can decide if we need to adjust the schedule for Beta and Final. In theory we can do that at any time, but in practice, if we drop Alpha, I think we should make a Schedule Review Checkpoint at approximately the same point in the schedule. I suggest we put a week before branching, it on the same day as "Change Checkpoint: Proposal submission deadline (Self Contained Changes)". That way allows us to include more time for those changes, and to even adjust the branch date if need be.

It is approved with the understanding that when the no more alpha change is submitted and if approved we will have to figure out exactly how that effects the schedule and will adjust it appropriately.

So, now that No More Alphas is approved, should this be reopened, or a new ticket filed to address any desired schedule adjustments?

I notice though that my suggested alpha-free adjustment puts the beta right in the midst of likely Flock dates (week of August 27th).

n.b. I edited my proposed schedule above to reflect the slipped F26 release, the inclusion of a mass rebuild, and to make explicit rather than implicit the beta rain date.

Updated with branch pushed back another two weeks:

2017-02-28
Branch Fedora 26 from Rawhide (Rawhide becomes future F27)

2017-06-20
Fedora 26 Release
Change Checkpoint: Proposal submission deadline (Changes requiring mass rebuild)

2017-07-04
Change Checkpoint: Proposal submission deadline (System Wide Changes)

2017-07-12
Mass Rebuild

2017-07-25
Change Checkpoint: Proposal submission deadline (Self Contained Changes)

2017-08-01
Change Checkpoint: Completion deadline (testable)
Software String Freeze (n.b. date subject to change pending discussion with translations)

2017-08-15
Branch Fedora 27 from Rawhide

2017-08-22
Software Translation Deadline

2017-08-29
Bodhi activation point

2017-09-05
Beta Freeze
Change Checkpoint: 100% Code Complete Deadline

2017-09-19 (Target date)
Beta Release

2017-09-26 (Rain date)
Beta Release

2017-10-10
Final Freeze

2017-10-24
Fedora 27 Final Release (GA)  (Target date)

2017-10-31
Fedora 27 Final Release (GA) (Rain date!)

AGREED: FESCo approves https://pagure.io/fesco/issue/1681#comment-432135 as the Fedora 27 schedule (+7, 0, -0) (sgallagh, 17:27:22)