Thorsten Leemhuis (fedora@xxxxxxxxxxxxx) 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 -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
