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.
-- fedora-legacy-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-legacy-list
