New Package Process

[Michael Schwendt]

On Wed, 27 Apr 2005 05:20:23 -0700, Toshio Kuratomi wrote:

> Not disagreeing but there needs to be some "Well-behavedness" guidelines so
> we know what is expected of a package to be put into CVS.
> 
> Here's my start for a list:
> * Follows naming guidelines
> * No one raises any legal issues
> * Passes security checks for upstream pristine sources
> * Passes security checks in spec file build/install scripts
>   - Unfortunately this means someone does need to skim through the spec.
> * Patches don't look malicious
>   - Unfortunately this means someone has to review the patches.
> * Packager shows commitment to fix issues raised

The last item being the most important one, most likely. If there's
disagreement on how to package something (e.g. file locations, uids/gids
and startup scripts in a non-trivial or complex package), packager and
reviewer should be willing to reach an agreement.

> We end up needing to do a pretty thorough review before package import --
> just not blocking cvs import on all the things that are found....
> 
> Someone else have some better ideas?

We run into the "mandatory vs. optional" trap again. This can be seen in
that you used the word "unfortunately" two times in your list. ;)

With a list of things to check, the longer the list, the more it scares
off reviewers _and_ package contributors.

Let's compare that with fedora.us. The "QA Checklist" was made for _all_
packagers, surely not just for reviewers. A packager, who didn't consider
the items on the QA checklist, didn't do his homework. A package with many
issues, both major and minor, is more difficult to review than a package
with only a few issues. It needs several steps to clean up a package if
you don't want to rewrite it from scratch.

I'd like to get back to one-step approvals of the form "reviewer examines
a src.rpm and can tell in a single message what things exactly would need
to be changed prior to approval". The risk, that a packager applies other
changes and introduces new issues, is always there. But I want to avoid
packagers asking "What else is needed?" and [probably impatient] questions.
When a contributor decides to sponsor a package, he should have a good
idea of whether or when the package is _ready_ and early classification
of issues into "blockers" and "nitpicking/beautiful-spec-writing".

I'd like to increase the learning experience, too, so reviewers ("package
sponsors") send their approval as soon as they feel good about the package
they reviewed, preferably as soon as the most important checks (from your
list above) have been done. If we don't do this, but import unapproved
packages, then review them over several days and with the help of comments
on commit diffs, and only then post an approval, it doesn't become clear,
who checked what. We still do have the possibility for contributors to
veto something after approval, and even after build to remove something
from the repository.