+1

I'm not sure this needs to be a blocker? I mean there's a month until final freeze...

But if everyone would like to make this a blocker, we probably need a bug filed and such, or else we will just vote on it, then forget it and nothing will track if it's done or not when we look at final blockers down the road. ;)

I'm -1 on making this a blocker. I doubt that the presence of any of these packages in the GA is so problematic as to require us to not ship if we don't get around to removing them. If there are specific packages that would rise to this level of concern, they should be raised as blockers following the normal process.

I'd be fine with shipping GA iff the packages could get yanked from the GA repo after the fact, but I guess that could have unintended consequences too.

Still, having packages in the repos for 6 more months than they should be will have unintended consequences too. Likely they will bitrot, get FTBFS / FTI bugs, and / or have confused users that get them via the repo but can't file bugs for them, etc.

And even though these packages will remain in the repos, any issues they have won't ever be able to be fixed because they're actually already retired on that branch (including security issues, etc.)

They can't be yanked from the frozen GA repo, but in the event that they somehow have critical issues and we NEED to remove them from users' systems, we have mechanisms for that. (Yes, that would be a BIG hammer.)

The idea of making this a blocker was to make sure it was tracked and completed prior to the final freeze, because we can't remove packages from a stable release after the fact. Maintainers retire packages to remove broken, unmaintained, or legally problematic content in the distribution and expect that packages are actually removed when they run fedpkg retire. That was broken for a while, and we don't know what type of broken, should-have-been-retired packages remain in the distribution, which is why I want to make sure this is checked prior to final freeze. If releng feels confident that this can be done in time, then maybe a FESCo release blocker is unwarranted, but I just figured it'd be a good idea to codify this.

But if everyone would like to make this a blocker, we probably need a bug filed and suc

I can file a bug (against the distribution component, I guess) if this is agreed on.

I'm gonna be Mr. Mean about the blocker policy again, because someone has to be: the blocker process is not a hack to get people to care about an issue. It is for tracking release blockers. The only things that should be release blockers are issues we genuinely will not ship the release without. I don't think this falls into that.

When there is a recurring problem with something that should be done not getting done, the fix for that isn't "stuff it into the blocker process so it comes up in a lot of meetings", it's "fix the process that should be getting it done".

Proposal: close this ticket here and track the issue in the releng ticket (12355).

Proposal: close this ticket here and track the issue in the releng ticket (12355).

I think that's the practical equivalent to voting "-1 blocker" here.

OK. -1 blocker.

FWIW, these should all be blocked now.

This got stuck with no resolution. Let's handle this during the meeting tomorrow.

We discussed this during the meeting today:
AGREED: Just close the ticket (+5, 0, 0)