Co-maintainersip policy for Fedora Packages

[Thorsten Leemhuis]

Bill Nottingham schrieb:
> 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.

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