On Thu, 2004-01-08 at 13:01, Ronny Buchmann wrote:This isn't that difficult. At Mandrake a diff of the changes (patches and .spec file) are put into the e-mail announcing the change. This gives the reader a quick & clear overview of what has changed. For the sources I would say: let the automated rebuild download them from the original place, and check the signatures.
On Thursday 08 January 2004 18:32, Steven Pritchard wrote:
My only other complaint, and it really is more of a suggestion, isIMHO this auto-built repository is the only testing repository needed.
that it would be *really* nice if the easy things (like "does this
package build") were automated. It would be *really* nice if the
automatically-built packages were put into a repository (accompanied
by USE AT YOUR OWN RISK warnings) that reviewers could download and
test from. At that point it becomes almost zero effort for interested
people (like me) to install a package on a test box and let it run for
a while.
People could test packages from there and than vote for inclusion in "stable" repo. This would simplify QA in a great way.
It took me a while to see this, but there really is a need for a two
step QA/testing process -- at least when you involve an autobuilder:
Pre-build:
Check for trojans and compromise attempts.
Auto-Builder:Check out SlBd: http://qa.mandrakesoft.com/twiki/bin/view/Main/SlBd at Mandrake this tool is used to automatically rebuild the ports (alpha, amd64, sparc and sparc64).
Does it build? Post-build: Check for proper operation of program.
You have to check the package for possible compromises of your autobuilder before you send it to be built.
What makes things interesting is that package QA consists of additional checks (look for unintentional security holes, check for enabled features at build time, spec file is "well engineered", secure default configuration, etc) as well. In fedora.us, these are done pre-autobuilder as well. I suppose the rationale for that could be, we have to take a look at the spec/patches/source/build to make sure the package isn't going to crack our autobuilder so we might as well do these other checks while we're at it.
=== There could be parallel testing of package security and package functionality if the tester received the prebuilt binary from the package author (AT YOUR OWN RISK). I'm not currently prepared to decide whether that would be a good idea or undermine the idea of QA, though....
-Toshio
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature