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

[William Stockall <wstockal compusmart ab ca>]

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?

Also, if there was little enough interest that no one tested the patch, 
why is it so important that it be rolled out at all?  If they are rolled 
out, they should at least be kept separate from the tested updates. 
That way people can choose whether they add that repository to pull 
updates from.


				Will.
Mike McCarty wrote:
> Eric Rostetter wrote:
>
> > Arg, sent with wrong From: address, so here it is again, since the 
> > moderator
> > probably won't get to it for a while...
> >
> > ----- Forwarded message -----
> >  Subject: Re: releasing updates-testing packages without VERIFY votes
> >       To: fedora-legacy-list redhat com
> >
> > Quoting Pekka Savola <pekkas netcore fi>:
> >
> >
> > > I suggest changing the policy so that packages in updates-testing
> > > which haven't got any VERIFY votes could:
> >
> >
> >
> > First, let me say that it would take less time for the people invloved 
> > in these
> > "lets publish without QA" discussions to just QA the packages than 
> > they are
> > spending arguing if we should publish them without any QA.  But, back to
> > the current point of discussion...
> >
> >
> > >  - after 2 weeks, marked with a timeout
> > >  - after the timeout of 4 weeks [i.e., 6 weeks total] be
> > >    officially published
> >
> >
> >
> > This goes against everything this group was founded on, and all Best
> > Practices.  However, it does seem to be popular with the few folks
> > involved in these conversations.  So, I'll approve of this, but only
> > if ammended to include the following:
>
>
> Well I don't. I object to it, period. It's not only not best practice,
> it's bad practice.
>
> If no one picks it up, and tests it, then how do we know it doesn't
> create a worse problem than it reputedly solves?
>
> [snip]
>
> Mike