Co-maintainersip policy for Fedora Packages

[Ralf Corsepius]

On Thu, 2007-01-25 at 11:17 +0100, Hans de Goede wrote:
> 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.

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

I only see one issue: Non-responsive maintainers and issues not being
addressed in "timely manners" rsp in "correct manners":


As I see it, the causes are manifold.

- In some cases it's a maintainer's "oversight"

- In some cases it's a maintainer's non-awareness about a problem.
(Many packaging mistakes/bugs fall into this category)

- In some cases it's a maintainer's ignorance about the consequences of
this deeds (The classical "FIXED RAWHIDE" falls into this category
"FIXED RAWHIDE == unfixed in "CURRENT")

- In some cases it's incompetence/lack of knowledge:
Maintainers do not address an issue because they don't know what to do
about it or apply arkward hacks, despite "specialists could easily help
out" (many autotool- and 64bit-hacks are from this class of problems).

- In some cases it's a maintainer being absent / having gone lost / not
listening / not following the lists / not being subscribed to a list an
issue is being reported (many of the broken EVRs issues fall into this
category).

...

So, in a nutshell: All I am proposing is, instead of forcing everybody
to bugzilla issues/bugs and to wait for a maintainer to consider doing
his job, let's build up some trusted teams who's task it would be to
address "clear and obvious cases" to take off some load from the actual
maintainer.



An alternative to building such teams would be to build a group of
semi-trusted "seniors" with "commit-after-approval" privileges. I.e.
somebody from this "senior" group who is not the "nominal maintainer" of
a package would have to present his diffs for review/approval to his
fellow "seniors" until his proposal has collected sufficient votes from
other "seniors".

Other projects (eg. the GCC project) implement all 3 models at once:
"Owners", "write after approval" and "card-blanche on specific problem
domains".

Ralf