Co-maintainersip policy for Fedora Packages

[Thorsten Leemhuis]

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

I think we are talking on cross purposes here. By "fix important bugs" I
meant "update to a new upstream release, test locally, commit to cvs,
build and get it out". I'll clarify the wording to make that more clear.

>>>> 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>
> [...]
> <end rant>

Okay, I removed that para.

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

So, HACKING file in CVS?

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

What I fear is this:

You have a number of foo packages. Foo-SIG is by default Co-maintainer
for all of them. New member bar (sponsored three days ago) gets member
of SIG foo (that *until now* often is nothing more then saying "I want"
and you become accepted). Now he has access to all Foo-Packages.

I think the solution I proposed (SIGs can't become co-maintainers) is
the best *for now*.

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

Hmmm. That would mean that we need to wait yet again for something. No,
I'd like to avoid that.

Cu
thl