RFC: co-maintainership, bug and package appropriation

[Patrice Dumas]

Hello,

This is a very long mail, sorry, but I thing the issue deserves it.
I think that the question of co-maintainership, bug responsiveness and 
the related issue of bug apropriation, package maintainership and 
orphaning are very important and are slowing down extras.

These issues have already been risen repeatedly, but I think there was
no agreement, although there were interesting discussions. And it 
pollutes a lot the debate on fedora extras eol versus non eol so I think
it deserves a specific thread, now.

I will first define co-maintainership, then propose some rules to help 
ameliorate responsivness on bugs, some rules for other package issues,
and last, rules for stalled reviews.

I suppose that a set of trusted contributors exists, I think that currently
it could be the sponsors. Later members of the security sig could be added.

I also use the term maintainer for the primary maintainer of a package.

1. Co-maintainership
====================

I think we should formally allow for co-maintainership. The primary 
maintainer can add co-mainatainers. He may revoke them at any time too.
The things that the co-maintainer is entitled to do are decided by the
maintainer, they are not necessarily public nor very precise, but 
obviously may be.

The co-maintainer receive all the bug reports for the package he is 
co-maintainer.

Technically I see a first possibility to mark somebody as co-maintainer, 
which would be to add his mail after the maintainer mail, separated
by a ',' in the 4th field of the owners.list file. There could of course
be any number of co-maintainer. If this is not technically possible, the
co-maintainer should be in the initialcclist, and there would be a wiki
page listing, for each package the co-maintainers (maybe with their roles).

2. Bug responsivness
====================

I think there should be different rules for different bugs. Here they are:

- Very serious bug: a security issue, buildsys screwing (remember 
  dap-server...).

  In that case the maintainer, a co-maintainer if it is in his role, or any
  trusted contributor may act upon the issue. Other contributors are urged
  to help draw attention to that issue by sending a mail to the 
  fedora-extras-list with an apropriate subject.

- Serious bugs: a bug that cause the application to fail building, crash
  when run and there is no workaround, prevent the package from being 
  installed.

  In that case if the maintainer or a co-maintainer if it is in his role
  haven't responded within 7 days, then the maintainer sponsor should take
  over responsibility for this bug, in person or by delegating to anybody
  else. If the maintainer sponsor cannot or don't want to do that, any 
  trusted contributor may take over responsability for that bug.

- Any other bug: nothing here, maintainer or co-maintainer if it is his role
  should act, but there is no time limit, no possibility of appropriation
  by others.

3. Other package issues and disputes
====================================

The above rules are not enough when there is no Serious or Very Serious
Bug, but some requests for enhancements or requests for updating and so
on, or when the maintainer never responds to  Serious or Very Serious
Bugs. This is more complicated because we want to avoid 2 pitfalls

- have packagers feel rejected
- have other packagers or users feel the extras packages are badly maintained

I see 2 major cases

1) The maintainer seems to be unresponsive. He never fixes himself the 
Serious and Very Serious bugs, never respond to other requests, never apply
fixes that other do, never respond to requests to be co-maintainer or have
a mail adress that seems invalid. My proposal is that in that case the 
sponsor, after enough evidence may nominate some people (including himself) 
to be co-maintainer(s) with the right to do everything. Apart from the fact
that it is not the maintainer who nominated him it is a normal co-maintainer.
So he should be warned than if the maintainer awake, he may be revoked.

2) There are disputes over significant design issues (update or not, fix
a given known issue that has different debatable way of being fixed), then
the issue should be thrown on the fedora-extras-list for a public debate,
and the sponsor should arbitrate the dispute. This possibility should only
be used when everything else has been tried and for important issues, it 
denotes a serious issue in communication and/or agreement in fedora extras 
goal. The sponsor may force the maintainer to chose a given alternative 
only if there is a wide agreement upon the fedora extras contributors, i.e. 
the maintainer is the only one defending his case. Otherwise the maintainer 
has the choice. We should really try hard to avoid forcing the maintainer
as he will certainly feel rejected.

4. Stalled reviews
==================

The rule above are not very suitable for stalled reviews, still that's also
a serious issue that may slow down fedora extras. I see 2 cases

1) the review is stalled because a fix for something is needed but nobody
has come with a fix. No problem here.

2) The fix is known, nothing blocks the review except that the submitter
doesn't implement what was suggested to him, or block the process otherwise
(don't apply for a fedora account although he was sponsored, don't do the cvs
import and so on). If somebody wants to take over the submission he should
say so in the bug report, and if the originial submitter hasn't responded
in 2 weeks, or the submitter has responded within 2 weeks that he was still
active but hasn't fixed the issue in 1 month, the new submitter should be
allowed to take over the submission, but taking as base the output of the 
current submission. The new submitter should allready be a fedora extras 
reviewer, it shouldn't be allowed to be sponsored in a package review when
the package review has been taken over. I don't know how this should be done 
technically, close that bug and reopen a new one, or keep on, changing 
the submitter or anything else, I am not a bugzilla expert. 




Remarks:

In my proposal the packages are never orphaned against their maintainer 
will. 

Last I think that it should be possible to revoke sponsors if they
are not playing their role, for example accept undue requests for 
co-maintainership of unresponsive maintainers.

--
Pat