Co-maintainersip policy for Fedora Packages

[Bill Nottingham]

Thorsten Leemhuis (fedora at leemhuis.info) said: 
> >> 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.

Generally, the bugfixing should be done upstream, not local to the
package. If there's not a lot of patching *specific* to the package,
most of the opportunities for conflict should go away.

> >> 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.

<speaking very very much for myself, and no one else>

OK, I'm getting tired of arguing this point with you. Your words say
it very clearly - 'make sure the community gets involved', 'differences
between red hat and community members'.

What those words say to me is that you don't think people in Red Hat are
now, or can be part of the community - that the community is always
entirely separate. And, frankly, I find that offensive.

If I want to co-maintain some game that Hans maintains, then I talk to
him, and it's irrelevant w.r.t. who signs his or my paycheck. If Josh
wants to co-maintain vte, then he talks to Behdad (or whomever), and
it's irrelevant who signs their paychecks.

If there are trust or other issues with how things are maintained, let's
hear them. But I'm not going to have some policy that mandates actions
based on some caste system separating maintainers into different camps.

<end rant>

> 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.

Sure, but this seems better suited for a user-level interface,
not a developer-level interface.

> >> 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.

You start out with 2 people dealing with all of the KDE packages.
Eventually, you keep adding people and you now have 10 co-maintainers
for all of KDE - it's now a de-facto SIG. So, I don't think saying
that SIGs can't be co-maintainers is the right answer, as I expect
SIGs will grow out of co-maintainership. Make more sense?

> >> 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?

Moving co-maintainers to ACLs vs. owners.list. Could go in owners.list
in the *owner* field, but that might break someone elses tools.

(Yes, I'm basing this on the code that's going to be deployed
to get the ACLs and notification set up.)

Bill