I don't know the reasoning for the original decision neither for the new one. I'm ±0.

So ... what do you actually want FESCo to decide here? Remove blocking status from the appstream-data update? I don't think we decide on freeze exceptions, do we?

@churchyard the reasoning behind originally making it a blocker was not clear in the meeting minutes. The reason for stripping it of blocker status is:

It's just getting the final metadata out so that we know what gnome-software displays up to date information

So while it's important to live images to have this, we don't feel it's worth blocking the release over.

@decathorpe I suppose FESCo could declare it's own FEs (although in practice that has never been done). So let's say the proposal is specifically:

An update of post-freeze appstream-data is not a release blocker

And the FE part is an assurance that we still think it's important and will let it in.

@decathorpe Before the fact that this is missing was noticed, RC 1.2 was spun (and has now completed). Technically, we have this listed as a blocker due to https://pagure.io/fesco/issue/1858#comment-506261 but upon a reread, I think that decision to be a "blocker" is misread. I think we were saying that we allow AppStream to update one day after the rest of Fedora goes into Freeze so it can pick up the latest updates as of Freeze.

So, proposal: Do not treat this as a blocker and allow RC 1.2 to be considered for release.

@sgallagh thanks for the clarification.

You have my +1.

and my AXE!^W +1

For further clarification, I think the blocker we had agreed on there was specific to that release because the AppStream content was actually completely broken, rather than just out-of-date. My memory of that time may not be perfect, though.

If my memory serves me well, I filed a FE request some ~5 releases ago asking for an appstream-data FE so that we can ship up-to-date appstream-data on install media (so that gnome-software has up to date metadata when running on install media / first install). sgallagh then asked me during a blocker review meeting to bring it to FESCo so that it can be added to release calendar so that we can be sure that it gets updated for every release. FESCo then declared it a blocker and it got added to the release calendar. This cycle it seems to have disappeared from the calendar though.

There may be slight inaccuracies in the story above but I think this is the gist of it :)

In my personal opinion, I think it makes sense to update it every cycle, but blocker is taking it a bit too far. Automatic FE sounds just about right here.

OK, it looks like we may have to spin up an RC 1.3 anyway, so this question may not be urgent any longer, but I'll revise my proposal to be more clear:

Proposal: Make AppStream updates an automatic Freeze Exception (documented here).

I don't have an opinion on whether we should bother with the schedule date.

Proposal: Make AppStream updates an automatic Freeze Exception (documented here).

+1

+1 tot Make AppStream updates an automatic Freeze Exception

I wonder if we should grant updates for other release-blocking packages (like new wallpapers) an automatic Freeze Exception as well? It seems like they need one almost every release anyway

+1

I wonder if we should grant updates for other release-blocking packages (like new wallpapers) an automatic Freeze Exception as well?

They already have some blockers.

An important difference here is that appstream-data need to be updated when everything else is frozen. Wallpapers can be updated before that.

+1

@sgallagh's proposal has been long APPROVED (+7, 0, -0)