QA process was Re: RPM submission procedure

[Stefan van der Eijk]

Toshio wrote:

>On Thu, 2004-01-08 at 13:01, Ronny Buchmann wrote:
>  
>
>>On Thursday 08 January 2004 18:32, Steven Pritchard wrote:
>>    
>>
>>>My only other complaint, and it really is more of a suggestion, is
>>>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.
>>>      
>>>
>>IMHO this auto-built repository is the only testing repository needed.
>>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.
>  
>
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.

>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
>  
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3403 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040108/81716568/attachment.bin>