Co-maintainersip policy for Fedora Packages

[Toshio Kuratomi]

On Wed, 2007-01-24 at 13:31 -0500, Bill Nottingham wrote:
> Thorsten Leemhuis (fedora at leemhuis.info) 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20070125/85cfdd15/attachment.sig>