On Wed, 2007-01-24 at 13:31 -0500, Bill Nottingham wrote: > Thorsten Leemhuis (fedora@xxxxxxxxxxxxx) said: > > >> 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> I don't like requirements here or elsewhere that mandate "X of the community and Y from Red Hat" for mostly the same reasons as you, Bill. However, I think what Thorsten is trying to address in this policy is the fact that currently, there's a block of Red Hat packagers that aren't really integrated or interacting with the community that has evolved around Fedora Extras. This is the cause of the Red Hat vs community mentality that has come out here. Now I think we want to shoot for a time when it won't matter who your employer is; if you are here to work on Fedora you have a niche within the Fedora Community. But to get there we have to acknowledge that not everyone who currently works on Fedora wants to be active in the community. Some people at Red Hat just want to do their jobs and go home; some people involved in upstream projects want to see their one specific package available for Fedora users and that's it. We have to address this, either by getting active community members to maintain/co-maintain those packages (Devrim Gunduz is an example of someone working to be a bridge between upstream postgresql projects and Fedora Packaging) or by making use of something like warren's proposal for multiple paths to advancement[1]_ and realizing that advancement needs to involve the interpersonal aspects of Fedora as well as technical savvy. If we don't address this we're always going to see a split that is stereotyped as Red Hat vs Community. [1]_: http://fedoraproject.org/wiki/Extras/Schedule/AlternativePathsOfMembershipAdvancement -Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
-- 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
