Perl splitting

[Ralf Corsepius]

On Tue, 2007-05-15 at 10:48 -0400, Robin Norwood wrote:
> Ralf Corsepius <rc040203 at freenet.de> writes:
> 
> > On Mon, 2007-05-14 at 11:19 -0400, Robin Norwood wrote:
> >> Ralf Corsepius <rc040203 at freenet.de> writes:
> >
> >> 
> >> >> >> 2. Such issues could easily be approached by a perl-SWAT team, but ...
> >> > I find it remarkable that none of you commented on this.
> >> 
> >> Are you volunteering to start one?  I'll be happy to help as much as I
> >> can, time permitting. :-)
> > Again, a comment I can't deny to find remarkable.
> >
> > I've been agitating to see "collaborative maintainership" to replace
> > this unfortunate "one-package/one-owner" maintainership policy in Fedora
> > ever since Fedora exists.
> >
> > So far, there have always been circles in Fedora which strangled any
> > such attempt.
> 
> 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.

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.

>   As
> you probably know, the vast majority of the recent changes to perl's
> spec file were contributed by spot and yourself - that's pretty
> collaborative. 
May-be in comparison to how RH had processed RFEs so far - I can't
judge.

>From my POV, things actually did not proceed substantially different as
they would have done before the "Core/Extras" merger. I could have
submitted patches as an RFE in bugzilla and wait for somebody @RH to
react.

>  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".

Ralf