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

[Eric Rostetter]

Quoting Rex Dieter <rdieter at math.unl.edu>:

> Michal Jaegermann wrote:
> 
> > Personally I think that if a "release early, release often"
> > principle would be applied to Legacy releases too, with a quick
> > re-release to follow for an occasional dud (which happened anyway),
> > we would be much further in the whole project.
> 
> Hear, hear.  Amen brother.  If it's not clear, I comletely agree with
> Michal.  An occasional possible broken release is better than no release
> at all.

While I generally disagree with the above, there are times when it would
benefit us.

We've had serveral kernel updates delayed because additional bugs are found
before we release a version that is in QA.  I disagree with this.  Release
them once they get QA, then fix the additional bugs and release again.

We have a nfs-config package held up for a similar reason.  It was in QA with
the upstream patch, and it fixes the problem as well as any other patch.
But a rare case was found where it doesn't fix the problem.  Well, why not
release it like every other vendor did (maybe even document the new case
it doesn't address).  Then go back and fix the new bug, and release again.

I hate seeing a perfectly good patch go through QA and then be put on hold
or held back while we try to patch additional bugs.  Release a version for
each bug if we need to, so that people are protected from each bug as soon
as possible.

But this is not the issue at hand.  We need to do QA, no two ways about it.
But let's not drop good QA because of new/additional bugs in the same 
package.

-- 
Eric Rostetter