releng

#12001 Getting Rawhide + 1 keys at least 2 weeks before branching
Closed: Fixed by jnsamyak. Opened by praiskup.

Closed: Fixed
Reopen Issue

We'd like to have Fedora Rawhide +1 gpg keys generated about ~2 (or maybe 4 weeks, if that's not a big issue) before the branching event happens. Right now it seems to be done on T-1 day which is most of the time OK, but sometimes quite stressful.

The first part of the request is perhaps about making a policy/rule, best-effort TODO item, or something like that. Dunno, ideas? So we could expect that Rawhide+1 keys keep appearing soon enough.

As an additional wish (sub-request), it would be nice to let people know that this key-generating event happened. The background story is that that this triggers events/processes in external teams (Mock, distribution-gpg-keys, Fedora Copr, Fedora CI, Packit, ...). I'm listening for the fedora-repos changes myself, and I'll try to start our external workflows "manually".. But I'm just an individual (and I make mistakes) ... so a question comes to my mind; can the update distribution-gpg-keys package become part of the branching process perhaps? (sure, we would process such task)

  • When do you need this?
    Before the next f42 branching. Then we can implement a trivial fix for the related mock-core-configs issue

  • If we cannot complete your request, what is the impact?
    If nothing happens, then we'll do what we are used to "externally"; and we'll keep trying to make the release mock-core-configs package "in time", and it will often work. But having keys sooner, we would have much less timing pressure and the #1338 issue wouldn't repeat for sure.

Metadata Update from @jnsamyak:
- Issue tagged with: meeting

So, I think we just did it a lot later than usual this last time. We ran into problems in the distant past not doing this soon enough and wanted to do them much sooner.

We used to for example generate the new rawhide key at branching time (or just right before it).

Anyhow, we already do make the key in advance, because it takes a week or so to resign everything with it before branching.

The 'rawhide + 1' here confuses me because rawhide changes depending on the time. :)

I'm not opposed to making the f43 key much sooner tho... say in the early part of the f41 release when things are more quiet? (so thats actually rawhide + 2 at that point right?)

I was confused, sorry. Agreed, let's call it Rawhide +2 (because it is being done before branching from "current" rawhide, not after)!

So, are we used to "misinterpret" the T-1 day note from https://docs.fedoraproject.org/en-US/infra/release_guide/mass_branching_checklist/ ? Because it seems that F42 (rawhide +2) was generated relatively early, around the branching of F41. Or, is there a typo and should we name it rawhide +2 in the doc?

I'm not opposed to making the f43 key much sooner tho... say in the early part of the f41 release when things are more quiet?

Exactly, this would be very appreciated. This would give us enough time to get prepared.
Edited by praiskup

So, looking at the f41 schedule:

https://fedorapeople.org/groups/schedule/f-41/f-41-releng-tasks.html

6   fedora-repos update with the new keys is available in updates-testing   Tue 2024-07-23  Tue 2024-07-23  0
7   Re-sign F41 content with F42 key    Tue 2024-07-30  Tue 2024-07-30  0

How about we move 6 to two weeks before mass rebuild, so that would be 2024-07-03 ?
Or would you like even eariler?

That sounds almost OK, I'm just not sure what happens if we skip the mass-rebuild point.
Could I happen say 4 weeks (schedule time constraint?) before Re-sign F41 content with F42 key?
It would be nice to have a note make sure that fedora-repos update with the new keys .. actually means F43, not F42.

Sure, thats ok with me.

CC: @jnsamyak @amoloney

+1 to that i dont see any issues for it

Metadata Update from @jnsamyak:
- Issue assigned to jnsamyak

We discussed this in the releng weekly call today, this proposal seems to be OK from the releng end, the next steps will be to ask @amoloney kindly :D to help me out to the point where I can open bz ticket or something to add it to the schedule so we don't forget!
Edited by jnsamyak

I'd offer a help, but updating schedule doesn't seem to be trivial :sweat_smile:

I'll mention this to Aoife, for adding it as well! But I think we can close this one

Metadata Update from @jnsamyak:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

Has this been implemented eventually? Just to not forget, I opened https://pagure.io/fedora-pgm/schedule/issue/170
Metadata

meeting

None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.