= Proposal topic = The non-responsive maintainer process is very complex and therefore I want to propose a much simpler alternative.
= Overview = I want to make the current procedure to become more a guideline about how many communication attempts should be made and the final procedure to become this:
1) Write a mail to fedora-devel with the problems of the package and a summary of communication attempts and open a ticket in FESCo to track all this. 2) If nobody from FESCo objects and two members agree after three days, the package can be reassigned.
= Problem space =
This proposal focuses on easy addressing the problems caused by non-responsive maintainers, which are out of date or broken packages that nobody fixes. The Fedora community seems to be sane enough to handle these problems in a good way without the restriction to actually write several mails in a certain timeframe to make sure that nothing bad happens. And even if a package is reassigned and the original maintainer becomes responsive again, then it will probably not be a problem to reassign it to him or her. If someone really feels that this procedure may be abused in some way, then this could be address if this really happens.
= Solution Overview =
The following wiki page needs to be updated: https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
There should also be an announcement be written to the fedora-devel-announcement mailinglist.
= Active Ingredients =
People who maintain packages for the Fedora Collection are primary affected. Also users of Fedora will experience better maintained packages. The workload on FESCo will probably increase a little, because the procedure might be used a little more.
= Owners =
Till Maas, Fas Account: till
This seems mostly sane, but I'm concerned about abuse of the process. For instance, if I wanted to take over a package maliciously, there's nothing to stop me from fabricating the supposed attempts to communicate in this process.
There is FESCo involvement, so that's somewhat mitigated. However, FESCo cannot be all-knowing, we're just humans after all, so there's still the potential for something to slip through.
I do however agree that the current process is long and laborious, and likely doesn't need to be, I'm just not sure what the right middle ground is.
Replying to [comment:1 jstanley]:
I don't understand how a malicious package take over can really cause trouble and how this should happen. Can you maybe describe a sample scenario of what should be avoided? Also the current process allows to lie about commnunication attempts.
There is also still a message to fedora-devel involved, so more than just one pair of eyes is looking at it. It could also be made a message to fedora-devel-announce, since it will probably not happen anymore, and then it will be even less likely that a malicious attempt will not be noticed.
FESCo approved a variant of this to add to the existing procedure:
"1) Write a mail to fedora-devel with the problems of the package and a summary of communication attempts and open a ticket in FESCo to track all this. 2) The ticket is discussed/voted on in the next FESCo meeting."
We are still interested in revamping the existing procedure, but we would like more discussion and feedback on the mailing list before doing that.
This addition still needs to be added to the wiki page and announced.
There was some minor change proposed to the fast track solution that got probably dropped by accident: Add the maintainer in question to CC of the mail to fedora-devel (which can off course be faked), but maybe it should also include to add the maintainers FAS name also the the Cc list of the fesco trac ticket.
This was agreed to at the 2009-09-18 FESCo meeting. Leaving ticket open until notification can be sent, but removing from the agenda.
written up on the wiki and announcement sent to fedora-devel-announce.
Closing now.
Login to comment on this ticket.