Ticket #251 (closed task: fixed)

Opened 5 years ago

Last modified 4 years ago

simplify non-responsive maintainer process

Reported by: till Owned by: kevin
Priority: major Keywords:
Cc: Blocked By:
Blocking:

Description

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

Change History

comment:1 follow-up: ↓ 2 Changed 5 years ago by jstanley

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.

comment:2 in reply to: ↑ 1 Changed 5 years ago by till

Replying to jstanley:

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.

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 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.

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.

comment:3 Changed 5 years ago by kevin

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.

comment:4 Changed 5 years ago by till

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.

comment:5 Changed 5 years ago by jstanley

  • Keywords meeting removed

This was agreed to at the 2009-09-18 FESCo meeting. Leaving ticket open until notification can be sent, but removing from the agenda.

comment:6 Changed 4 years ago by jstanley

  • Keywords writeup added
  • Owner set to kevin

comment:7 Changed 4 years ago by kevin

  • Resolution set to fixed
  • Status changed from new to closed

written up on the wiki and announcement sent to fedora-devel-announce.

Closing now.

comment:8 Changed 4 years ago by kevin

  • Keywords writeup removed
Note: See TracTickets for help on using tickets.