+1 to postponing the checkpoint.

Is the RPM 4.14 change supposed to be in this list? It looks like it was approved two weeks ago.

Note this test-list thread — I think there's a pretty good argument that we made a mistake in setting the change checkpoint where we did, and that it should have been set at the branch point. (These two were initially both set for this week, but then we moved back the branch without also moving back the deadline.)

Now seeing it in actual action, I think the branch point makes most sense:

A) If it's testable, cool, it goes in the branch.

B) If it's not, and work hasn't landed in rawhide yet, fine; it can go into rawhide at any time after the branching. If partial work has already landed but isn't ready, it should be backed out of the branch and continued on rawhide only.

None of this really makes sense two weeks before the branch, at least not without offering lightweight branches where the work can happen (side tags for every change?) and even then the two-week thing doesn't seem necessary.

@mattdm RPM 4.14 is special, major parts of it were backported to current rawhide, so our current plan is:

• After branching we put some kind of 4.14.0-alpha to rawhide
• Keep it there for few weeks
• If no issues left (assuming people reported them and we fixed them) -- push it to F27

then at some point make beta / rc / release before Final Freeze.

And while re-reading your comment, I think RPM 4.14 was approved before deadline. But it's kinda impossible to have change completion deadline while mass rebuilding is happening (because we wanted to backport things which directly affect build artifacts before mass rebuild and everything else after).

This ticket was discussed in last Friday's FESCo meeting. FESCo has decided to give the items that were approved last Friday one more week for the Completion deadline.