#361 Updates and cleanups for release process docs
Merged by kevin. Opened by adamwill.
adamwill/infra-docs-fpo freeze-variables-update  into  master

Download 361.patch

This started out as a small change to drop references to
RelEngFrozen and clean up references to Frozen, but it got...
bigger.

We drop the sop_bodhi_activation page entirely (it is redundant
with the beta_freeze page, but worse).

beta_freeze page changes:

  • General style/grammar cleanups
  • s/Bodhi activation point/updates-testing activation point/g
  • Clarify that freeze and u-t activation are distinct events
  • Drop an obsolete warning and steps related to a now-fixed Bodhi bug
  • Clarify and standardize ansible variable changes
  • Correct the list of playbooks to be run (koji-hub is needed as
    it depends on Frozen, the removed ones are not needed)
  • Move the body of the email announcement into the SOP so the
    release number can be templated (this is now consistent with
    final_freeze)
  • Simplify stable push instructions
  • Drop fedora-beta.conf creation - duplicated with beta_RC_compose
  • Drop incorrect text from Consider Before Running section

beta_release page changes:

  • General style/grammar cleanups
  • Clarify and standardize ansible variable changes
  • Correct playbooks (add koji-hub), move to logical place in order

final_freeze page changes:

  • Clarify and standardize ansible variable changes
  • Fix empty 'Process stable push requests' section

final_release page changes:

  • Clarify and standardize ansible variable changes
  • Drop pungi.rpm.conf.j2 changes - depends on:
    https://pagure.io/fedora-infra/ansible/pull-request/2471
  • Add multiple missing playbook executions
  • Update the reference PR to F41

sop_mass_branching changes:

  • Correct the list of playbooks to be run - both Bodhi playbooks
    are needed, MBS is gone, and there's a stray $ sign in one

Signed-off-by: Adam Williamson awilliam@redhat.com

@kevin @jnsamyak please review!

https://pagure.io/releng/pull-request/12588 drops the mail templates from the releng repo.

Ah, so here we see the RelEngFrozen vs Frozen.

Frozen was for infrastructure, since it freezes after beta/final freezes (later the same day). It's close enough I suppose we could just fold into this.
RelEng frozen was also different so it could be lifted at final release friday, but the infrastructure 'freeze' could lift the day after the new release was out.
In this case tho, it doesn't matter for final freeze as the release cycle will update.

So, I guess we could... just means there's a smaller window to land last changes before the infrastructure freeze.

Except here... infrastructure is still frozen until the day after the release happens.

Hmm. The only thing in ansible that actually uses the Frozen variable is roles/koji_hub/templates/hub.conf.j2 , where it's used to decide whether the 'block' action is allowed for Branched. That seems like something that relies on the distro freeze, not the infra freeze?

We could rename Frozen to NextReleaseFrozen or something like that, to make its purpose clearer? And then we'd maybe have InfraFrozen too, theoretically, except there is no current user of it.

Right, "Frozen" is more intended for humans. It allows them to know when they can push changes normally, or need to get +1s (because the host / group is frozen)

I'm ok with renaming things to make sense, but I think it's valuable to have a concrete way to tell 'hey, this host is frozen'.

The "Frozen" and "RelengFrozen" was split because the infrastructure freeze and the release freeze are not 100% matched up. The infra one usually starts after the release one (to allow for folks to land any in progress work, but I suppose we could align there. But it's also not matched up on ending... releng needs is 'freeze' to end on the friday before release so bodhi can push updates. Infrastructure needs it's freeze to end the day after release.

How is a human meant to use it, to know whether a 'host or group' is frozen? For that purpose I'd assume it'd be read into the MOTD string on relevant systems, or something, but AFAICS it is not? It's really only used by roles/koji_hub/templates/hub.conf.j2 .

I'm fine with calling the thing we're setting here, and which Koji uses, something else, I'm just confused about how things are meant to be right now.

I proposed the names I did because they seem more precise, BTW. RelEngFrozen isn't really right, because not all of releng is frozen. Rawhide isn't frozen. Stable releases aren't frozen. It's only the pending release that's frozen. Hence, NextReleaseFrozen.

Calling the other one just plain Frozen seems ambiguous - what's frozen? InfraFrozen seems like it expresses the intended meaning...

It's mentioned in every freeze announcement email...

ie,
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/message/KNX5QZOWQOW6ZAWJIGKN7YM57CN6DA26/

I'm ok moving it to 'InfraFrozen', but we will need to make sure any docs mention it correctly...

aha, hmm. well if we've been doing that, maybe we should keep it as just 'Frozen' despite the ambiguity. I'll tweak this PR in a bit.

@adamwill, the PR looks good to me; it is much neater. Thanks for removing duplicate changes. I am hoping to merge this once you get your tweaks done from the Frozen section as discussed above^

rebased onto b2f3b6589aec46f605b6de7290a7d2bb473545d2

Well, now I look at it: that message does not mention any ansible Frozen variables at all. It mentions the script in the ansible-infra repo which tells you which hosts freeze, but that script doesn't use any Frozen variables.

Still, I've gone ahead and submitted https://pagure.io/fedora-infra/ansible/pull-request/2481 to split Frozen into InfraFrozen and NextReleaseFrozen, and updated this PR so all the freeze and release SOPs specify to update NextReleaseFrozen.

rebased onto b2f3b6589aec46f605b6de7290a7d2bb473545d2

rebased onto b2f3b6589aec46f605b6de7290a7d2bb473545d2

rebased onto b2f3b6589aec46f605b6de7290a7d2bb473545d2

rebased onto b2f3b6589aec46f605b6de7290a7d2bb473545d2

I've also updated this PR so the infra release process SOP now documents how to start and end the infra freeze, since it didn't really cover that before. It specifies to update the InfraFrozen variable when appropriate.

Looks ok to me. We can iterate further changes... Thanks much for fixing things up.

Pull-Request has been merged by kevin

Metadata