Co-maintainersip policy for Fedora Packages

[Hans de Goede]

Michael Schwendt wrote:
> On Thu, 25 Jan 2007 11:17:20 +0100, Hans de Goede wrote:
> 
>>>> 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.
> 
> "Touching your packages" and "upgrading your packages" is not the same.
> Why, oh, why are breakage scenarios like that used as a main argument
> everytime there is a discussion like this?
> 

Because:
1) I've sponsored several people and in general that meant having to
    teach / coach them until they become familiar enough with packaging
    issues and guidelines to give them the green light. At that point
    most of them still weren't really good packagers, think of them as
    just graduated from school and now learning the real stuff in
    practice.
2) One of THL's main arguments for this co-maintaining is to allow new
    (unexperienced) contributers to get into the game by co maintaining
3) New (unexperienced) contributers are likely to not know the
    difference between touching and updating.

That doesn't mean I'm opposed to all this, it just means I'm critical.
I for one wouldn't let a new (unexperienced) contributer, co-maintain
any (delicate) libraries as the chance for breakage is just too high 
(IMHO). OTOH I have plenty of simple / small package for which a 
co-maintainer would be more then welcome, and in that case to actual 
handle things like new upstream versions, fix small packaging bugs etc.


Regards,

Hans