Script to determinate packages wich need comaintainership

[Jeff Spaleta]

On 6/18/07, Jochen Schmitt <Jochen at herr-schmitt.de> wrote:
> Jeff Spaleta schrieb:
> I'm not sure, that upstream authors are willing to handle with distribution
> specific standards and issues.

And I'm not sure that maintainers who are not involved in upstream
development can fix
more important codebase bugs that have absolutely nothing to do with
packaging guidance and standards.  I've got the packaging guidance
covered pretty well. What I need are upstream developers who are
invested in working with me to run point on codebase bug issues not
more packaging experts that can collectively stand around and scratch
their heads with me when a real software bug is exposed.  Of course
whether or not an upstream developer is willing to be involved with
fedora packages will be a case by case basis. But right now I don't
really have the ability to chat up developers upstream of me to get
involved more directly. Contribution is an all or nothing affair at
the moment.. we are not leveraging our infrastructures strengths to
build bridges between package maintainers and upstream developers.

>
> Of course it should be possible to invite a upstream author which is not
> a fedora contributor to be a comaintainer for a specific packages, but I
> think this is not the common situation.

Actually we dont have a way to do that. The sponsorship process does
not have a concept of probationary access or mentored access. You get
sponsored and you get the kings to the kingdom.

> A comaintainter should ensure, that someone is available, if a fix on a
> package is necessary, which doesn't allow a delay, because the maintainer
> is in vacation and so on.

Again.... I want to stress... that not all problems are shallow
packaging problems. Some are in fact deeper problems in the codebase,
that expert knowledge of the packaging guidance will not help. For
these much more important problems, being able to have an upstream
developer work with me within the fedora infrastructure to produce
scratch koji builds in response to specific bugreports is the best way
to fix problems quickly.

Packaging level issues at the end of the day are just shallow
annoyances, even when its multilib problems, compared to crasher or
data corruption bugs in the codebase itself.

-jef