QA-process for new packages

[Michael Schwendt]

On Tue, 05 Oct 2004 09:01:08 -0400, Michael Tiemann wrote:

> > > Silke, I'll volunteer to be one of your reviewers.
> > 
> > Good to hear that. Though, Silke's packages are held up by packages
> > at the bottom of their dependency chain, e.g. shapelib:
> > 
> >   https://bugzilla.fedora.us/show_bug.cgi?id=920
> > 
> > That package blocks four other tickets, so one would guess the
> > packagers would try to get it released with higher priority. Would be
> > much appreciated to get your comments there.
>
> Please tell me what I need to do.  If I need to be a package reviewer
> for shapelib, I'll do that.  If I need to lobby people inside Red Hat,
> I'll try to do that.  I think it's hugely important that Fedora be a
> good host for GIS software users and developers.

[Actually, this particular package is called "proj" (shapelib is
another one in the dependency chain).]

Bug 920 would need somebody to answer the questions raised in the
last comment and preferably post a GPG clearsigned approval in
accordance with the fedora.us package submission and QA policy
( http://www.fedora.us/wiki/PackageSubmissionQAPolicy ). [1]

Currently, there is no other way to get packages published. And for
new contributors--package developers as well as reviewers--there is no
other way to earn trust, well, except for submitting flawless
packages. While it would be easy for me, or one of the other trusted
developers, to verify whether a new contributor is who (s)he pretends
to be, it would need much more before I would declare that I trust him
or her with regard to creating packages and/or direct access to the
build system and repository. Release manager resources are finite,
too, and for instance, I wouldn't like to see the build team encounter
an increasing number of failed builds (or updates which would be
published without QA and would break the repository). Definition of
"trust" is one of the major problems.

What holds up many packages in the fedora.us QA queue is lack of
community commitment. For the few people, who review and approve
packages regularly, reviewing and approving hundreds of special
purpose packages (e.g. educational programming languages) is beyond
their time and motivation. Especially, since many packages don't even
build, or don't seem to work when they build, or raise many
questions. More than 60 people have submitted packages. But only few
of them help eachother to get the stuff approved.

Seeing progress in terms of official Fedora Extras, and a contributor
recruitment process guided by Red Hat, would be helpful, too. With
some people at fedora.us it seems as if they would like to get a
package included, but when they are told that the package doesn't
build or has bugs/problems in several places, they don't respond or
sound as if they accept suggestions only reluctantly. As if they think
they can save themselves the work because everything will become more
easy (like the old Red Hat Contrib mess) with official Fedora Extras.

-----

[1] As a side-note, one can argue about alternative ways how to
package "proj". For instance, in the NetCDF package request, the
issue of polluting the /usr/include namespace has come up.
Installing header files into an own directory below /usr/include,
or headers and libraries into an own tree below /usr/lib/foo,
is a common technique to avoid namespace pollution and to allow
for parallel installation of multiple library versions. But
usually, such issues don't block a package from being published
as long as there are no file conflicts [yet].

-- 
Fedora Core release 2 (Tettnang) - Linux 2.6.8-1.521
loadavg: 1.38 1.38 1.41