Make sure branching isn't right after FLOCK or any other major Fedora related conference. Release engineers are then jetlagged so it is harder for them to maintain everything correctly.
Leverage rawhide gating in the next branched Fedora. Set it up for gating just like Rawhide (this time we didn't).

I fully agree with these 2 statements.

Disable allowing new builds in for the new branch until we have a compose. This would have saved us many days of people landing broken stuff we had to sort out. We could at least get a compose to have to start with. The next compose might get a pile, but at least we don't have to fight a moving target. The builds will be enabled as soon as the first compose is created.

Could you please provide some more details about this? Like we don't create f31 branch (in case of f32 branching) until we have successful compose?

Stop rawhide composes until we have a branched compose. First to avoid confusion from having links to a Rawhide which is diverging from a branched Fedora. Second to avoid problems like COPR and others (including my team) who are using Rawhide for testing before the compose is available.

I'm strongly against this as a rawhide user. We should not block rawhide by anything, we do snapshot of it at some point and stabilize it instead.

Make sure branching isn't right after FLOCK or any other major Fedora related conference. Release engineers are then jetlagged so it is harder for them to maintain everything correctly.

This is a good idea, but we'll need to figure out what it actually means.

• How do we define "right after"?
• The schedule is set well before Flock is planned, so would the expectation be that Flock is scheduled to avoid this or that we should adjust the release schedule after Flock is set?
• If we adjust the release schedule how does that impact other milestones? Right now, all schedule milestones are effectively anchored off the target release date. If we have to delay the branch point to accommodate Flock, do we move the release date out or do we compress other parts of the schedule?

Make sure branching isn't right after FLOCK or any other major Fedora related conference. Release engineers are then jetlagged so it is harder for them to maintain everything correctly.
Leverage rawhide gating in the next branched Fedora. Set it up for gating just like Rawhide (this time we didn't).

I fully agree with these 2 statements.

Disable allowing new builds in for the new branch until we have a compose. This would have saved us many days of people landing broken stuff we had to sort out. We could at least get a compose to have to start with. The next compose might get a pile, but at least we don't have to fight a moving target. The builds will be enabled as soon as the first compose is created.

Could you please provide some more details about this? Like we don't create f31 branch (in case of f32 branching) until we have successful compose?

I'm thinking similar rules could apply here like during beta/final freeze. People could make a new builds but these builds won't get into the compose before there will be the first compose. That's why there is a sentence: "The next compose might get a pile, but at least we don't have to fight a moving target."

To answer your question, yes, there should be f31 branch created.

Stop rawhide composes until we have a branched compose. First to avoid confusion from having links to a Rawhide which is diverging from a branched Fedora. Second to avoid problems like COPR and others (including my team) who are using Rawhide for testing before the compose is available.

I'm strongly against this as a rawhide user. We should not block rawhide by anything, we do snapshot of it at some point and stabilize it instead.

I don't want to block Rawhide getting updates but if the above rules would make the compose appeared in a few days than I don't see this as a significant problem.

Make sure branching isn't right after FLOCK or any other major Fedora related conference. Release engineers are then jetlagged so it is harder for them to maintain everything correctly.
Leverage rawhide gating in the next branched Fedora. Set it up for gating just like Rawhide (this time we didn't).
I fully agree with these 2 statements.
Disable allowing new builds in for the new branch until we have a compose. This would have saved us many days of people landing broken stuff we had to sort out. We could at least get a compose to have to start with. The next compose might get a pile, but at least we don't have to fight a moving target. The builds will be enabled as soon as the first compose is created.
Could you please provide some more details about this? Like we don't create f31 branch (in case of f32 branching) until we have successful compose?

I'm thinking similar rules could apply here like during beta/final freeze. People could make a new builds but these builds won't get into the compose before there will be the first compose. That's why there is a sentence: "The next compose might get a pile, but at least we don't have to fight a moving target."
To answer your question, yes, there should be f31 branch created.

This is already the case for final freeze, because we only push stable packages that fix accepted blocker or freeze exception bugs.

For beta it's not because we branch and only enable bodhi 2 weeks later.

Stop rawhide composes until we have a branched compose. First to avoid confusion from having links to a Rawhide which is diverging from a branched Fedora. Second to avoid problems like COPR and others (including my team) who are using Rawhide for testing before the compose is available.
I'm strongly against this as a rawhide user. We should not block rawhide by anything, we do snapshot of it at some point and stabilize it instead.

I don't want to block Rawhide getting updates but if the above rules would make the compose appeared in a few days than I don't see this as a significant problem.

Yeah, ideally this never happens. Perhaps any approved policy should leave this up to releng... if it's too long a time, they could restart rawhide or something.

Make sure branching isn't right after FLOCK or any other major Fedora related conference. Release engineers are then jetlagged so it is harder for them to maintain everything correctly.
Leverage rawhide gating in the next branched Fedora. Set it up for gating just like Rawhide (this time we didn't).
I fully agree with these 2 statements.
Disable allowing new builds in for the new branch until we have a compose. This would have saved us many days of people landing broken stuff we had to sort out. We could at least get a compose to have to start with. The next compose might get a pile, but at least we don't have to fight a moving target. The builds will be enabled as soon as the first compose is created.
Could you please provide some more details about this? Like we don't create f31 branch (in case of f32 branching) until we have successful compose?
I'm thinking similar rules could apply here like during beta/final freeze. People could make a new builds but these builds won't get into the compose before there will be the first compose. That's why there is a sentence: "The next compose might get a pile, but at least we don't have to fight a moving target."
To answer your question, yes, there should be f31 branch created.

This is already the case for final freeze, because we only push stable packages that fix accepted blocker or freeze exception bugs.
For beta it's not because we branch and only enable bodhi 2 weeks later.

Thanks for correcting me.

Stop rawhide composes until we have a branched compose. First to avoid confusion from having links to a Rawhide which is diverging from a branched Fedora. Second to avoid problems like COPR and others (including my team) who are using Rawhide for testing before the compose is available.
I'm strongly against this as a rawhide user. We should not block rawhide by anything, we do snapshot of it at some point and stabilize it instead.
I don't want to block Rawhide getting updates but if the above rules would make the compose appeared in a few days than I don't see this as a significant problem.

Yeah, ideally this never happens. Perhaps any approved policy should leave this up to releng... if it's too long a time, they could restart rawhide or something.

+1

Did we just move the still ongoing discussion from the mailing list to this ticket? Isn't that leaving people out?

We discussed this during today's meeting:
ACTION: nirik to restart the discussion on fedora-devel

Posted back to the list thread and asked for more discussion there.

Thank you, @kevin.

Let's discuss this on mailing list and open a new ticket with actionable items afterwards.