no mandatory QA testing at all [Re: crazy thought about how to ease QA testing]

[Jeff Sheltren]

On Feb 11, 2006, at 1:32 AM, Pekka Savola wrote:
>
> I agree that this would complicate the process further.
>
> I have proposed something simpler, and still do:
>
> 1) every package, even without any VERIFY QA votes at all, will be
>    released automatically in X weeks (suggest: X=2).
>
>    exception: at package PUBLISH time, the packager and/or publisher,
>    if they think the changes are major enough (e.g., non-QAed patches
>    etc.), they can specify that the package should not be
>    automatically released.
>
> 2) negative reports block automatic publishing.
>
> 3) positive reports can speed up automatic publishing (for example: 2
>    VERIFY votes --> released within 1 week, all verify votes:
>    released immediately after the last verify)
>
> There is no need (IMHO) to grade packages to more or less critical  
> ones.  Every QA tester and eventual package user uses his or her  
> own value judgment.  If (s)he fears that the (potentially untested)  
> automatic update would break the system, (s)he would test it before  
> two weeks are over.
>
> Publishing positive reports can be made simpler but that probably  
> isn't on the critical path here.
>

I think this is a good idea, and I'd like to add something to it:

What I'd like to see is to have something like this (Pekka's idea  
above) happen for regular package contributors (people that have  
submitted multiple packages to FL).  People that haven't submitted  
many packages should require one of the trusted packagers/builders to  
do a "publish" QA before pushing the package to testing.  Since the  
current state of things is that it's only a small group of people  
doing things, this won't really affect anyone at the moment- but it's  
just a way to ease new packagers in while being sure that they are  
submitting "good" packages.

Fedora Extras does something similar:  Once a packager gets  
"approved" to package something, they are able to push updates to  
that package without any formal QA at all.  Of course, all changes to  
the package are sent out to an email list which is monitored by all  
(well, most of) the packagers, so there is some passive QA going on.   
All this would be easier to setup once FL is using a CVS setup to  
track package changes, but in the meantime I vote for something along  
the lines of what Pekka suggested.

-Jeff