Reviewing qcad (was: Re: fedora.us package requests)

[Michael Schwendt]

On Thu, 23 Sep 2004 18:56:14 -0600, Rodolfo J. Paiz wrote:

> On Thu, 2004-09-23 at 12:58, Michael Schwendt wrote:
> > Yes, it needs a lot. The automatically created debuginfo package alone
> > is >30MB. Compressed that is.
> 
> Qcad installs and runs properly, even (yay!) inserting itself properly
> into the FC2 GNOME menu structure. At least for my user... I don't know
> if it does so system-wide (which I would guess is the correct default).
> 
> How do I comment on this inside Bugzilla? You mentioned a GPG-signed
> review, Michael... I don't have a GPG key yet. What else do I need to do
> in order to provide a useful review to Fedora.us? I mean both in terms
> of actually reviewing the software and in terms of providing the
> information to Bugzilla.

That's what we need to find out [1]. ;) 

With the current procedure as documented at

  http://www.fedora.us/wiki/PackageSubmissionQAPolicy#review

only GPG signed comments, which include at least the md5sum checksums
of the visited src.rpm file and the included source tar.gz [2] (which
you need to compare with what the upstream project has released),
classify as reviews.

You would include brief comments on everything else you find relevant,
e.g. whether you tested installing, upgrading and erasing the package
(sometimes post-uninstall scriptlets are broken), whether you've done
any run-time tests (even mentioning that the application starts would
be helpful, because some builds terminate immediately with
segmentation fault :), and whether or not you've done low-level
technical checks of the package .spec file and included patches (if
any).

No harm would be done if you wrote that you think the application runs
fine, but you're uncertain about any packaging errors and hence you
would want to suggest publishing the package in "testing" or
"unstable" rather than "stable". Once published, it could be moved
later if it's considered good enough or fixed with updates till it's
good enough.


[1] I stick to my opinion, that the current "QA checklist" as
published in the fedora.us Wiki aims at package developers and hence
covers mostly technical issues. It should be the packagers themselves
who use this list to avoid common mistakes in their packages prior to
submitting package requests. It need not be reviewers who verify such
technical packaging details. While low-level QA may avoid packaging
pitfalls and improve the average quality of published packages,
high-level [run-time] QA would be much more important (and difficult),
e.g. testing for stability, regression, upgrade path sanity, security,
...

[2] There are different strategies on how to verify tarball
checksums. Some upstream projects provide detached signatures which
can be downloaded and verified, provided that you trust the signer (or
the people who signed his key). Some upstream developers respond to
emails or on IRC and send you MD5 checksums. Querying rpmseek.com or
other sites for existing packages from other big/popular distributions
can be helpful, to compare with what content they packaged. Else,
source code diffs against the previous or older releases are very
helpful. And, of course, monitoring upstream projects release habits
closely, i.e. when, where and how they publish and announce new
releases.

-- 
Fedora Core release 2 (Tettnang) - Linux 2.6.7-1.494.2.2
loadavg: 2.55 2.15 1.81