RFC: Updated co-maintainership proposal -- policy part

[Thorsten Leemhuis]

Thorsten Leemhuis schrieb:
> On 14.02.2007 23:06, Brian Pepple wrote:
>> /topic FESCO-Meeting -- Encourage co-maintainership -- all, thl
> FYI, I reworked the last proposal and some FESCo members looked over it 
> and seemed to agree with it so far, too. See
> http://www.fedoraproject.org/wiki/Extras/Schedule/EncourageComaintainership
> for details. Please comment.

FESCo discussed this in its last meeting and agreed that this is roughly
the way forward. So I'd like to put the current proposal up for
discussion here so we can shake out the last details now, as that's
easier then doing it later (side note: of course everything can later be
adjusted if we want or if there is a need to; stuff like this always
needs to be adjusted over time in my experience).

So here is the policy part of the proposal. I'll send the guidelines in
a separate mail.

----
== Policy ==

All packages in Fedora Extras shall normally be maintained by a group of
maintainers. The most important reasons for it: One maintainer can
commit fixes like patches or new upstream releases that fix important
bugs (for example security data-corruption issues or packaging bugs that
confuse the users systems) even when the other maintainer(s) are away
from keyboard due to traveling, sleeping or whatever. Maintainers
further can help, guide and watch each other, which should lead to a
better overall package quality.

The goal is to have at least three maintainers per package in total and
at least two per supported distribution release. Big and important
packages should have more maintainers -- there is no upper limit. There
is a primary maintainer who takes care of the package in general; it's
his job to approve and find new maintainers and to make sure their
efforts get coordinated -- especially between different branches like
EPEL and Fedora. Then there is a primary maintainer per distribution
release -- that's often the same as the primary maintainer; bugs get
assigned to the per distribution maintainer, who is in charge of the
package. It does not mean that he has to do all the work, but he has to
make sure the work gets done!

The maintainers should actively work towards getting at least one
co-maintainer and also try to get the seconds one -- for now that means
ask around one the mailing list now and then for people that might be
interested in the job. The goal is to have that process mostly automated
-- e.g. let a script parse the owner informations and send out mail to a
mailing list now and then that contains a list of the packages that do
not have enough co-maintainers yet.

The primary maintainer can not block co-maintainers for distributions he
doesn't want to support -- e.g. if he does not want to care about his
package in EPEL he has to accept that someone else takes care of it in EPEL.
----

Comments?

Cu
thl