This is something we wanted to do since a long time but we never got a chance. Now, we want to implement this but we have couple of questions regarding the timing.

Firstly, i would really like to thank you guys for looking into this. I know you guys are very busy and taking out time to do this means a lot for Fedora in the long run.

Since i proposed this originally, let me see if i can take try to answer this :)

Original Proposal:
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/thread/VYUGK76GLI2PSDVSCQEIEONP7YJP7NC2/
So, as I understand it, it has to start 4 weeks before branching and send notifications for 8 weeks and then go with the orphaning and retirement process. But that means orphaning and retirement happens after branching? Which means we have to do it on both rawhide and branched?
This seems like a lot of confusion and during our RelEng meeting on Feb 14th 2019 we want to propose a change to this:
We want to change it to start after branching but in rawhide only and send N weeks of weekly notification before orphaning.
This sounds ok to me, as long as the package is orphaned from the next version of this distro, it should be fine.

Also, wanted to confirm if its really 8 (N=8) weeks of notifications or can we reduce it shorter? Since 8 weeks after branching means, we are close to the release.

Again, shorter period is fine for me, the main purpose is to give the package maintainer time to either resolve the bug or close it as "not relevant for fedora"

Also, since the tooling is not setup yet, can we skip it for F30 and start doing it for F31? We will try to get it in F30 but at this point, it seems a bit far-fetched.
Sure, i understand!
Thanks.

We want to change it to start after branching but in rawhide only

Please no. We don't want to have security-buggy packages in a new Fedora release right of the bat. The retirement should definitely happen also in branches. I think we should simply retire the package both in branched and rawhide. Since this has to be automated anyway, this doesn't increase the work in any significant way.

During the FESCo meeting on Feb 18th 2019 we decided to retire them way before branching so that people will have time to reintroduce them if needed and this helps us to do it only in rawhide rather than in both, branched and rawhide.

So, here's my proposal, once a release gets out and we start working on branching on next release, there are about three and half months of time which is 14 weeks.

We can start this process 10 weeks before branching and send weekly notifications for 4 weeks and retire them after 4 weeks of notifications, which gives them 6 weeks to get them back into distribution before branching. 6 weeks before branching because if a package is retired for more than 2 weeks then they have to go through the review process which takes time sometimes.

Please let me know what you all think?

+1 to proposal. There is still the question of what to do for f30 tho. IMHO we should do some nagging/test runs... tell people the new policy and show what packages are affected by it, but otherwise not orphan/retire until f31.

+1 to @mohanboddu's proposal. I agree with @kevin that we should not orphan/retire until F31.

+1 to proposal. There is still the question of what to do for f30 tho. IMHO we should do some nagging/test runs... tell people the new policy and show what packages are affected by it, but otherwise not orphan/retire until f31.

There are currently 104 components which are affected by an open important or critical level security flaw. If you want, i could send an automated mail to all of them.
Attaching the list here as well.

+1 to @mohanboddu's proposal. I'm sad that this doesn't happen on f30, but I guess it is really a bit late now :(

+1 to the proposal

There are currently 104 components which are affected by an open important or critical level security flaw. If you want, i could send an automated mail to all of them.

I think this would be good. Let's try to push people to fix or close as many of those as possible.

This was discussed in today's FESCo meeting:
AGREED: mboddu's proposal https://pagure.io/fesco/issue/2090#comment-554540 is approved (+7, 0, 0)