Adding the 'meeting' keyword. I think we should discuss whether there should be a policy change around primary ownership.

I'm going to make the following proposal to amend the non-responsive maintainer policy:

In the event of a primary owner who is not sufficiently performing their packaging duties and for which there exists a co-maintainer who is doing so instead, the co-maintainer should request that FESCo promote the co-maintainer to owner and demote the owner to a comaintainer, retaining all ACLs.

This way, the former owner may at any time resume partial maintainership of the package, but the continuing maintenance will fall on the new owner.

As a set of straw-man guidelines (feel free to chime in with better ones), FESCo should automatically approve any ownership request for which a package has gone through one complete Fedora cycle with updates from the comaintainer and none from the former maintainer. Requests that do not meet this guideline should be proposed for discussion at the FESCo meeting and voted upon.

This will not and should not be an automatic process. This shall only occur at the initiation of a comaintainer by way of a FESCo ticket.

Stephen, I think that there might be cases where even currently non-comaintainer could request such reassignment. So I'd like to slightly amend your proposal:

In the event when primary owner of a package is not sufficiently performing their packaging duties and there exists another maintainer (preferably existing co-maintainer of the package) who is willing to do so instead, he should request that FESCo reassigns the package to him and demote the current owner to a comaintainer, retaining all ACLs.

... The rest can be probably kept.

Replying to [comment:2 tmraz]:

In the event when primary owner of a package is not sufficiently performing their packaging duties and there exists another maintainer (preferably existing co-maintainer of the package) who is willing to do so instead, he should request that FESCo reassigns the package to him and demote the current owner to a comaintainer, retaining all ACLs.

How to quantify the "packaging duties"?

If the hypothetical duties are not met does this mean that anybody who is willing to mantain (so no co-mantainer) can ask directly to Fesco and avoid waiting a month before getting access? Example here (again myself on dkms):

https://bugzilla.redhat.com/show_bug.cgi?id=965712

http://thread.gmane.org/gmane.linux.redhat.fedora.devel/180513

Replying to [comment:3 slaanesh]:

How to quantify the "packaging duties"?

Well, my straw-man guidelines were attempting to address this. I was offering one simple set of rules for basically-automatic approval and then suggesting that for anything other than this egregious case a ticket should be open for FESCo to discuss (similar to provenpackager approval).

If the hypothetical duties are not met does this mean that anybody who is willing to mantain (so no co-mantainer) can ask directly to Fesco and avoid waiting a month before getting access? Example here (again myself on dkms):

I think that's a pretty reasonable addition, yes. I think that fits with tmraz's addendum cleanly (which I agree with).

Both sounds very good to me...

Adding Andreas to the ticket so that this isn't a surprise and to allow him to participate in this discussion.

The straw-man guidelines make sense to me in general. I don't much like ratifying them and immediately using them, OTOH if FESCo has the power to do such ownership changes even without having general guidelines...

So, a few things to note:

a) The only difference between a "primary owner" and a co-maintainer with all the acls is that the "primary owner" email address is listed in bugzilla as 'assigned to' and the co-maintainer is cc'ed. This is because bugzilla cannot assign a bug to multiple people at once.

b) in pkgdb 2.0 I think we are going to look at changing this to show that role as 'primary contact' instead of anything else. Perhaps semantics, but I think it describes things more accurately, as well as allowing people to specify a contact who perhaps would triage reports before reassigning them to other team members.

In any case since this distinction doesn't really make much difference I'm probably fine with saying we will do this on a case by case basis if requested and the primary maintainer isn't responsive.

(may not be in the meeting)

1) In this specific case, I'm fine with assigning it to slaanesh. He's been doing primary maintainership (essentially) since 2011.

2) In the general case, I'm OK with it as a general principle, but with the bits added about any packager being able to request this, it's effectively a full replacement of the nonresposnive maintainer process. I'm a little leery of immediately acking that without more discussion, even if it reads OK as a start.

Resolutions from the Jun 5 meeting:

• AGREED: ownership change requested in #1120 is approved (+7)
• AGREED: Nonresponsive maintainer policy update (+8): s/Fast Track/Exception/. replace first paragraph with: "There are some cases where it may be needed to reassign a package even if this procedure has not yet finished. Examples include when many dependencies are broken, version updates are needed for security or stability reasons, or maintainer response prevents the nonresponsive process from proceeding without actually resuming maintenance. In such cases, this exception procedure can be used."

notting will update the wiki.

Wiki updated.

Many thanks!

--Simone