I propose change the rule for 3 months at least. And if we have package in stables branches and just was retired in rawhide . I propose that package can be unretired without re-review . Now that we will have many retired packages if we notice that they are required for other packages we may unretired quickly, is better , to keep next release in shape .
I think 3 months is probably too much. But 2 weeks is really rather short.
And if we have package in stables branches and just was retired in rawhide . I propose that package can be unretired without re-review.
This makes sense to me.
I though in propose 6 months, more or less one release. Or before mass branching, now that we are testing rawhide before mass branching, makes sense . See [1] we need to un-retire a package just in rawhide , because tests made shows that we need that package ...
[1] https://pagure.io/releng/issue/8120
As one of the folks involved in the original policy, I can agree that two weeks is too short because it's possible for an unannounced or accidental retirement to go unnoticed for a while. Rawhide could fail to compose for a while and then a broken deps report would have to show up. The distro used to be much smaller and these things were more obvious.
So I agree with extending the time. I think six months or even three months is a bit too long, though, so I would propose perhaps a month or six weeks.
I do not agree with skipping the re-review simply because the package exists in one non-EOL release. Since it's not possible to retire the package in a release branch, this would effectively extend the time for most retirements out to something well over a year.
Note that I do not see a re-review as a much of a burden. If the package was in good shape then the review should be trivial. If the package was not in good shape then the review is certainly necessary.
Also note that some special cases can also be exempt from the review process.
Yes, 2 weeks is very short. How about 2 months then?
better than nothing !
+1 for two months
I guess it took too long to notice that a package was retired because the dependent packages were not retired. So maybe when allowing for a longer time to unretire pkgs, it makes sense to also adjust other limits to retire packages faster.
To simplify calculations it would be better to base it on weeks instead of months, for example 8 weeks instead of two months.
+1 for 8 weeks ,
I agree that this change, let us retire packages with more confidence , i.e. if we could retire and unretire more quickly, we could adjust next release more freely and with less work .
My problem is the work that I will have to unretire a package that I even I'm not sure that is relevant .
We got sidetracked by discussing the specific durations. It seems that 8 weeks is the most popular option.
So let's vote on 8 weeks to make a formal stamp: PROPOSAL: package can be unretired without re-review for 8 weeks.
+1 FTR
+1 to 8 weeks
We're at (+4, 0, 0) for the "8 weeks" proposal. Let's wait one more day.
+1 to 8 weeks.
APPROVED: package can be unretired without re-review for 8 weeks (+5, 0, 0).
Metadata Update from @zbyszek: - Issue tagged with: pending announcement
https://fedoraproject.org/w/index.php?title=Orphaned_package_that_need_new_maintainers&type=revision&diff=535808&oldid=535801
Metadata Update from @psabata: - Issue untagged with: pending announcement - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
well , if we want unretire one package for F32 (in cycle of development of F32 ), 8 weeks is not enough , for example : rocket-depot
Login to comment on this ticket.