Ralf Corsepius <rc040203@xxxxxxxxxx> writes:
> On Tue, 2007-05-15 at 10:48 -0400, Robin Norwood wrote:
>> Well, what does collaborative maintainership mean to you, exactly?
> A team of equal (senior-, overseer-) maintainers simultaneously working
> collaboratively on something.
>
> Not "a subordinate coding-monkey submits" something to a "devine
> maintainer", who applies a submitted change with several weeks of delay
> inbetween.
>
> Of cause this requires some amount of trust and some amount of
> "self-distrust" and "self-reality check" ("I would like to ... but am
> not sure about it/this is not my domain ...").
>
> Cf. how e.g. GCC works. Many people have privileges to access all files
> of the GCC source tree, but are supposed only to touch certain files or
> certain areas.
>
> Wrt. perl rpms, the same principle could mean a "perl-packaging SWAT
> team" updating BR's of perl-module packages to reflect changes having
> been incorporated into the main perl.
I'm not entirely sure how this would work in practice - the obvious way
is to add a group of people as co-maintainers to all packages in the
perl-* namespace. But I think we would want to ask existing maintainers
before doing this to their packages, and I'm not sure how new perl-*
packages would work, except by someone manually taking care of it (maybe
if the package review process for new perl packages included this step.
Would this be good enough? Do you have a better way?
> Wrt. to the main perl package, this could have meant Spot, Ville or me
> to apply our patches ourselves and us having rebuilt the packages after
> you would have OK'ed the patches. It would have lifted some burden off
> your shoulders without many side-effects.
I'd be totally ok with this. Can I take this thread as a request by you
to be added to the list of maintainers for perl? Spot had mentioned
being added himself recently. Ville? Anyone else?
>> If you want commit access, one of the benefits of the
>> merge is that you (or anyone else with a track record) could become a
>> co-maintainer of any package in Fedora, not just the 'extras'. We
>> wouldn't want just anyone to have commit access, obviously. Personally,
>> I wouldn't want to get rid of the maintainer idea entirely, either - I
>> think the personal responsibility and accountability implied by the
>> maintainer role count for a lot.
> It might surprise you but I don't disagree on this. There always needs
> to be some "authority with the final say", be it an individual or a
> committee or simply "majority". In GCC it's coordinated by applying
> different "patch policies" on different development branches and by
> "approving patches/patch reviews".
>
> Wrt. FC this could mean: "Write after approval to any 'senior Fedora
> developer' on 'rawhide'", "Maintainer write-only on releases".
I think the release engineering and infrastructure teams are looking at
these sorts of rules, but the tools don't exist yet, AFAIK.
-RN
--
Robin Norwood
Red Hat, Inc.
"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching
