Fwd: Re: releasing updates-testing packages without VERIFY votes

[Mike McCarty]

Benjamin Smith wrote:
> On Friday 23 September 2005 10:03, William Stockall wrote:
> 
>>I concur with Mr. McCarty.  If untested updates are moved in with the 
>>tested updates then NONE of the updates can be trusted.  Who wants to go 
>>back to the bug entry to check for sure if an update actually got tested 
>>prior to rolling it out?
> 
> 
> So don't release them to the same place... 
> 
> What if a repo is set up just for these timed out packages, and if somebody 
> wants to use them, they can set their yum.conf to include this "semi-trusted" 
> repository? 
> 
> If the package is given a name like  
> bison-1.28-7.FEDORA-LEGACY-TIMEDOUT

This would be acceptable to me, at least. My main issue is that people
always get only what they want, and can know that for a fact. If I point
to a repository and do a yum update, and then see the list of things
that would be done, I don't want to wonder how much, if any, has
actually been through QA. If the non-released stuff is put into a number
of categories, then that's not a problem, so long as one can set ones
options to pull from those areas or not, as one wishes.

> Then it would be easy to see what you have installed that you might consider 
> checking out by piping the output from "rpm -qa" thru grep. 
> 
> I think this answers both sides of the equation, the underlying question seems 
> to be "Does the risk of not publishing security updates exceed the risk of 
> installing untested packages?" 

And gives the end-user the power to make that decision, rather than
the developers. Which is what I'm interested in. I want to control
what is on my machine, without a lot of labor.

> Would this add much to the administrative overhead for these packages? 

Dunno, but it looks ok to me. If the developers don't mind the
extra work (and I'm sure it is some extra work), then that's fine.

One little reservation I have: This must be carefully documented.
The end-user must be made aware of exactly what is in each of the
repositories and how it got there, and what the percieved pros and
cons are for pulling from each piece of the repository.

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!