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
