RPM submission procedure

[Michael Schwendt]

On Thu, 08 Jan 2004 00:14:24 -0500, Jef Spaleta wrote:

> I'm not going to take anything away from someone who is able to build
> 500 packages and place them into a repository and build a userbase.

But is it a userbase that uses all 500 packages? Or is it a userbase that
uses only a fraction of the available packages? IMHO, it is the latter. If
Joe User is smart enough to install and configure a package tool to point
it to one repository, he's also smart enough to point it to a different
repository in case the former one provides a non-working package. Don't
count on Joe User to take the time and submit a bug report by private mail
or via a mailing-list. He would rather proceed and try an alternative
package or downgrade or build from tarball. It's a similar scenario when
Joe looks for a newer version. If repo X doesn't include it, he takes it
from repo Y. If he's courageous enough at all, he posts in a web-based
message board and is pointed to an arbitrary package offered at some site
which is reported as working. It is a common attitude that plain users
expect the developers to fix problems automatically, disregarding the
possibility that the developers might not even know about a problem.

> If for some reason, god forbid, Dag had to stop
> producing packages for personal reasons, that's a big blow to the
> archipelago concept since there are no written policies that I know of
> that others can follow to reproduce what he has accomplished.         

Excellent example. One can argue whether all of Dag's tools are available
and documented and whether someone could mirror the src.rpms and take over
the repository in such a case. But one would still need to duplicate the
infrastructure, the man-power and the commitment which is required to
maintain all that.

> And now we come to the crux of the issue. Coming to a consensus among
> ALL the interested parties about what the actually priorities are in the
> process pretty much defines what the packaging community is going to
> look like:
> How transparent do the QA processes NEED to be? 

QA is a _huge_ problem, in particular if there is no complete list of what
to check, but also if there is a list and reviewers go through it step by
step and don't develop a feeling for what other issues could be important.
Package reviewers have a very different point of view with regard to
package quality. Some would want to actually test-drive the built software
for an extensive time while others would concentrate on technical details.

> How much input from the community does there NEED to be? 

Certainly bug reports, RFEs and communication/feedback from users.

> How hard do you want to try to make sure all the packages meet the same
> level of quality? 

Define "quality".

> How important is it to make sure all the packagers are using common
> conventions and best practices when writing build scripts?

The user doesn't care about technical issues, such as spec files or
included patches and integration work. But if multiple developers are
supposed to maintain a package, they better agree on how to package
everything.

Fedora.us supplies a spec file template. A skeleton of how an initial spec
could/should look like and what is considered readable and clear. But it
should not be misunderstood to such a degree that upon minor package
upgrades, packagers start changing indentation style and order of spec
file fields to match the latest template closely.

Packaging is not "art", it is an engineering task. We should focus on
packaging software correctly, not on beautifying a build script. We should
avoid trying to be overly smart and not use lots of macros or conditionals
to make a package build on more than our target platforms. Spec files
should contain comments where it helps to understand the process of
setting up and building a piece of software.

--