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
