On Mon, 2004-11-29 at 09:02 +0200, Pekka Savola wrote:accounts). Is there any chance of making the update creation and verification a bit simpler, so that it wouldn't take so damned huge amount of work to get an update out..?
It would be nice to simplify the process so more users can contribute. Do you have any suggestions?
OK, let me try to see if I could improve this a bit.
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.
Documenting the process very clearly and providing tools to help in the process:
- the QA Testing process needs to be much more explicit on what _exactly_ should be done at each step of the process:
1) REQUIRED to do
2) RECOMMENDED to do
- 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"?
The same applies to the rest. We'll need a (hopefully short and concise) list which we can point people to, and say "follow these 3 steps and you're done." If it's a lot of steps (more than, say, 5), we'll want to create scripts to help in the process -- e.g., one which compares the original SRPM and the updated SRPM and shows the results (recursing through tarballs etc.); one that does the same for binaries; etc. -- I think these have already circulated on a list half a year ago or so.
There should also be more documentation at least on following:
1) documenting new vulnerabilities (I think Jesse has mostly been doing this) -- in bugzilla?
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.
3) how do you go about from proposing an updated package (in response to 1), and how that gets into the build system.
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
-- fedora-legacy-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-legacy-list
