how to improve the efficiency

[Tom Yates]

On Fri, 3 Dec 2004, Pekka Savola wrote:

> Use of Bugzilla:
> - having to register a fedora.us bugzilla account, it would be better to use 
> RH's bugzilla if possible/reasonable.
> - bugzilla being too user-unfriedly; for example, the GUI at
> http://bugzilla.fedora.us/query.cgi has _way_ too many options and scares 
> people away.  You'll definitely want something simpler, like the interface 
> Red Hat is using.
>
> Use of PGP signatures:
> - Is it necessary to use PGP signatures when reporting at bugzilla? Bugzilla 
> already provides user authentication, so this only gives relatively little 
> additional protection.  It's much simpler if you would not need to hassle 
> with PGP at all if you just want to report whether a package works or not. 
> It's (more) OK to require the use of PGP for those who submit the actual 
> packages, etc., though.

i know this may sound contrary, but - as a fairly new tester - i figure 
i'll post a different viewpoint.

i don't care which bugzilla i use.  mozilla remembers the passwords for 
me, and it's fine to let it do that, as gpg provides the real security. 
i don't find it a hassle to gpg-sign my postings, and i think there's a 
real benefit there; password authentication isn't as secure as a digital 
signature.

i never use the search engine on bugzilla; thanks to the excellent 
round-up postings which include links for all the relevant packages, i can 
go direct to the page to report results.  but you may be right about the 
complexity of the engine.

> - For example: updates-testing says:
>
>   1. Download the binary RPM package from the updates-testing channel.
>   2. Verify the integrity of the downloaded package (see 
> http://www.fedoralegacy.org/about/security.php).
>   3. Install the package, and note any installation problems.
>   4. Use the package (as appropriate for the package), and note any problems 
> found.
>
> These must be more explicit.  What exactly must be verified at "2"? How do 
> you report being successful after "4"?

as to how to report success, it's fairly clear to me that a "++VERIFY", 
with sha1sums of the relevant packages, suffices.  i can't remember how i 
worked that out, though, so it may well be useful to be clear about it.

regarding 2, i take my lead from other reports.  people tend to post a 
one-liner about the nature of the testing: "installed, ran a couple of 
simple python scripts, it works", or "i use mod_ssl extensively, about 
15,000 squirrelmail transactions were made with the new module, it works" 
and let whomsoever is making the "publish to updates" decision decide 
whether or not my testing suffices by way of verification.

i assume that's better than some arbitrary standard ("you must run at 
least two different scripts, or conduct five web transactions, or ten 
desktop transactions, with the new package"), but i'm happy to be told 
that i'm doing it wrong, and some other way would be more helpful.

> 2) how you proceed if there is new vulnerability in the same package which 
> is already in the process but not released to updates yet.

again, i've left that to the publishers.  if i'm running a package from 
updates-testing, i report it via bugzilla, trying to include detail 
without prolixity, and let the powers that be decide if my input is of any 
use.  if something more focussed would be more useful, then please let the 
powers say so!


-- 

   Tom Yates
   Cambridge, UK.