Co-maintainersip policy for Fedora Packages

[Bill Nottingham]

Thorsten Leemhuis (fedora at leemhuis.info) said: 
> Fedora Extras for a long time wanted to have more than one maintainer
> per package as that has several advantages (see below). But until now we
> never had a policy how it should look like and how it those maintainers
>  should work and interact. I took some time and wrote something up.
> Please comment!

I suspect finding three people that care about every package is going
to be hard, although I'd love to be proven wrong.

My main comment is it does seem like a lot of policy/procedures around
something that might be better to grow organically - a lot of the should/
shall seems better suited to be 'are encouraged to'.

> All packages in Fedora Extras shall normally be maintained by a group of
> maintainers. That has several benefits; maintainers for example can
> watch and help each other. One maintainer further can fix important bugs
> (security, data-corruption, whatever!) even when the other maintainer(s)
> are offline (traveling, sleeping, whatever).

*cough* Upstream! *cough*

> Packages primary maintained by Red Hat employees should
> have at least one co-maintainer from the community. They should try to
> hand over certain regular maintain task to the the community; that
> should help getting the community involved everywhere and to get some
> load of the Red Hat employees so they can focus on more imporant things
> -- that's best for both sides!

How is this different than the rest of the policy? One community,
maintainers are maintainers, co-maintainers are co-maintainers. Trying
to draft specific policy based on locality seems like a bad idea to
me.

> The primary maintainer can set individual guidelines what his
> co-maintainers are allowed and what not; be has to put them into the
> wiki at Packages/<package-name>/MaintainerRules . A hint to that page
> should be as comment on the top of the spec file.

Seems overkill to me, leads to dependencies in system A (package SCM)
to absolute paths in system B (wiki), etc.

(comemnts about dispute resolution in another mail)

> SIGs can't become co-maintainers per-se. Rather they should observe the
> packages or make sure that SIG members are co-maintainers.

Leads to a big grey area w.r.t 5/10 maintainers vs. a SIG.

> We require the PackageDB and some other technical things to really make
> above policy possible. Until we have those it works like this:
> 
>  * the general and primary-maintainers for each release are always
> identical (exception: EPEL); it's the one that listed as first in
> owners.list
> 
>  * co-maintainers all get listed in the last field in owners.list
> 
>  * there are no ACLs yet in the VCS, thus we need to find ways to live
> without them

Slight counter proposal:

- primary maintainer is the one in owners.list
- co-maintainers are the ones in the ACLs. Add yourself to initial CC
  if you'd like. (These, unfortunately, are separate)
- further waits on the package db.

>  * all packages should have at least two co-maintainers

See above. TBH, I don't see that we're drowning in maintainers - how
is someone that co-maintains 50 packages better than someone that
maintains 20?

Bill