Bill Nottingham schrieb: > 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. Note that there are a lot of "should" or "the goal is" in the policy, and not "must have". So if there is not interest in a package its fine if there is only one maintainer for a package. I'll add this to the proposal: Nobody can be forced to maintain packages, so sometimes it might happen that a package has only one maintainer. That's fine, but the maintainer should now and then ask other contributors and also interested users to become co-maintainers -- that will get more people involved into the project and is better for the package and the project as a whole. > 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'. Well, co-maintainership can be used for a long time (okay, bugzilla was broken for a long time, too), but a lot of people did not care much about it (in other words: it did not grow organically). Some people also seem to have a "this is my package, don't touch it" attitude, which is not good for the project as a whole. Thus I think the benefits are worth the procedures. And as I said: there are a lot of "should" or "the goal is" in the policy, and not "must have". >> 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* -ECantFollow The Fedora maintainer still needs to import a new upstream version that fixes stuff. I'm all for having upstream maintainers as co-maintainers that can commit and build updates if there is a strong need to, but most often that won't be the case. >> 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. I hope that para can vanish over time, but I think it's worth it for now, to make sure the community gets involved everywhere so the differences between red hat and community members then will hopefully nearly vanish. >> 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) I fail to see a suggestion what you would like to see. I considered to use the VCS for the MaintainerRules file, but my feeling was that the wiki was the better place for it. BTW, having a "Packages/<package-name>" for most of our packages or another form of easy to modify package webinterface (I'd prefer a mix of wiki and automatically generated pages) is something we should work towards in the longer term in any case. >> 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. Not sure if I can follow you here. >> We require the PackageDB and some other technical things to really make >> above policy possible. Until we have those it works like this: >> [...] > Slight counter proposal: [...] I fail to see the exact differences. The outcome seems to be mostly the same, you just seem to say it with different words. Or what did I miss? >> * all packages should have at least two co-maintainers > See above. TBH, I don't see that we're drowning in maintainers That, IMHO, is the a big problem with the current scheme and the reasons why I'm driving this forward. If I today would want to become a packager for Fedora I'd not know how. All the stuff that I use is packaged already. I could package something I don't use else to get involved, but that's not really a good way IMHO. With the new scheme I can ask packager foo: "Hey, you maintain a lot of packages. I'd want to become a packager, too. Can I help you as co-maintainer for package bar to get more involved?" Yes, we need some other stuff (PackageDB, Alternative paths of membership) to make that work, but most of it is in the planing stages already. > - how > is someone that co-maintains 50 packages better than someone that > maintains 20? That why there is the "Don't maintain too many packages" section. I extended it a bit to make it obvious that co-maintaining a lot of packagers is a bad idea, too. CU thl -- 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
