Bill Nottingham schrieb: > Thorsten Leemhuis (fedora@xxxxxxxxxxxxx) 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 -- 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
