Co-maintainersip policy for Fedora Packages

[Hans de Goede]

Thorsten Leemhuis wrote:
> Linus Walleij schrieb:
>> On Thu, 25 Jan 2007, Ralf Corsepius wrote:
>>> E.g. a team of "packaging specialists" being granted "card blanche
>>> privileges" on "packaging issues" (...)
>>> At least to me, e.g. wrt. packaging, in obvious cases, this would spare
>>> me a lot of time, because bugzilla'ing takes much more time than
>>> directly fixing something.
>> You're right. And I notice that I also stated before that most of the 
>> Fedora core people (loosely defined term but definately including Ralf) 
>> are welcome to change and rebuild any of my packages at will.
>>
>> Actually the idea of strict ownership evades me, I would rather prefer a 
>> more Wiki-like attitude (once you have a Fedora ID account and PGP key) - 
>> "BE BOLD", "If in doubt, fix it".
>> http://en.wikipedia.org/wiki/Wikipedia:Be_bold_in_updating_pages
> 
> +1 -- I'm all for that, too, but every time I proposed something like
> the above somewhere I got quickly shot down by other people.
> 
> But the proper place for that IMHO is not the co-maintainers policy.
> It's IMHO the "when to touch other peoples packages" policy. When I
> wrote that I even tried to grant some "packaging specialists" access
> everywhere, but as I said: People did not like it and preferred the
> bugzilla way even for obvious fixes.
> 

I'm not sure where I stand here, on one hand, I like the idea of being 
able to fix other peoples packages as bugzilla indeed sometimes is a 
slow path. OTOH I don't like people touching some of my packages without 
me being in the loop somehow. This differs from one package to the 
other, some are quite straight forward, others however are not and are 
easy to break. Take Ogre for example, a minor update from 1.2.3 to 1.2.4 
from upstream might seam harmless there, but upstream tends to break the 
ABI every update! Some other maintainer trying to help is likely not to 
know this and thus create problems, so I don't want other people 
touching Ogre without asking me first.

I think that we need todo 2 things:
1) Define the problem we are trying to solve. It seems that part of the
    problem is the bugzilla path to get fixes into others packages is
    slow. Replacing the bugzilla path is only one answer to this part of
    the problem, why not first find out why its slow (in some caseS) and
    see if we can remedy this.
2) Have a way to mark packages as ok to touch / don't touch. As said
    I know that some of my packages are easy to break if handled wrong,
    others OTOH should be fine candidates for other to fixup if a fixup
    if needed, or even candidates for someone to take over if he/she has
    an interest in doing so.

Regards,

Hans