= phenomenon = The administrators refused to unretire a package which was claimed only a few hours after getting retired because the letter of the policy requires a rereview when claiming a retired package. But this completely misses the spirit of the policy, which is to prevent bitrot in packages orphaned long ago, not to make it a pain to resurrect a package retired due to miscommunication.
= background analysis = Our policies are being followed too much too the letter and common sense has been lost.
= implementation recommendation = Either or both (probably both) of the following: (a) Amend the unorphaning policy by adding: "As an exception, packages which were retired reasonably recently may be unretired without going through the rereview process. Package database administrators should unretire these packages on request." (b) Implement a new "common sense policy": "Use common sense. In case of conflicts, this supersedes all other policies."
We need more decisions taken through thought processes, lenience and helpfulness and fewer decisions taken through inflexible bureaucracy and rigid policies.
Where can we see this request and refusal?
Personally, I'm all for us trying to empower maintainers rather than restrict them.
It's however unclear to me if any request was made and to whom? (There's a thread, but that was 2 weeks after the package was orphaned, and I see 0 posts from someone who wants to maintain the package).
Setting meeting keyword for next week's meeting.
Even if I agree with Kevin Kofler, I don't know how can we force engineers to unretire package in these cases. Would it help to add a note like: And if anyone asks for unretiring in few hours after retirement, add it back?
I'm +1 for something like my own proposal, because I can't attend the next meeting.
FESCo agreed on the following clause:
Packages may be unretired without review up to 2 weeks after retirement providing that the package has ever previously been reviewed.
Login to comment on this ticket.