QA process was Re: RPM submission procedure

Panu Matilainen pmatilai at welho.com
Fri Jan 9 16:13:13 UTC 2004


On Fri, 9 Jan 2004, Michael Schwendt wrote:
> On Fri, 9 Jan 2004 11:54:51 +0200 (EET), Panu Matilainen wrote:
> 
> > The fact that you need two such 
> > users outside of "trusted developers" to get the package *anywhere* 
> > doesn't do much to encourage people to do QA because it feels like totally 
> > wasted effort since the package isn't still moving. 
> 
> But if the first reviewer has done most of the work already, a second
> review can be like a piece of cake. Or is everyone waiting for someone
> else to be the early bird?

Sure it's a piece of cake, but *somebody* has to do it. If you look at the 
average package in fedora.us QA queue there are *very* esoteric packages 
in there.. in many cases you'll be lucky to find just that one person who 
understands/is interested enough to learn what the package is about *and* 
willing to do the few steps of QA review.

> 
> With regard the notion of "untrusted/trusted developers", I favour the
> concept of giving "untrusted developers" the chance to take responsibility
> early by relying on their review. That means, if there's a package request
> ticket with a PUBLISH vote, I assume the stuff has been reviewed actually,
> so let's apply some of the mandatory sanity checks only, skim over the
> rest and get it published, taking the first "untrusted" review into
> account.  Heck, if that first review was half-hearted, there's still the
> PENDING step, and the packager shouldn't "sleep" either and be somewhat
> familiar with a package, too, before it is approved.

I agree - but the way it's expressed in our current policies doesn't come 
out sounding like that. At least to me, the policy sounds basically like 
"you have to do the same checks the other guy did" meaning pretty 
redundant and boring work somebody already did... So if others agree, we 
should at least rephrase the "publish vote from two untrusted developers" 
to something which expresses what you say above better than the current 
policy.

> 
> *Sometimes* the packager does most of the QA already, anyway.
> 
> > I've been lobbying lowering the entry bar to testing/unstable for a while
> > now... Stable repository should IMHO remain basically as it is, eg you
> > can't get your package there until it's seen a full QA review under
> > current rules. However allowing just one "untrusted" developer QA review
> > to get package into testing or unstable would at least give people the
> > feeling that their effort is valuable and actually helps. 
> 
> Bears the problem that people would be entirely satisfied with getting
> their packages published in testing/unstable easily and don't care to get
> them into "stable". It shouldn't end like RHContrib, but it would be
> worth a try: +1

Oh, I certainly don't want another RH contrib. I want to *lower* the bar
to get packages out in the field, not remove it :) People are not going to
be satisfied by just getting their packages into testing/unstable but it's
a *start* - it's much easier to get users to test something they don't
have to build themselves. How the actual move happens from testing to
stable.. I don't know really, certainly it shouldn't be of the form "if
nobody complains in 10 days move it a level upwards". We've had the
discussion a few times, always non-conclusive, as to how to actually use
the stable/testing/unstable structure beyond what the packager originally
asks for. Just an off-the-cuff idea: if one trusted, or two untrusted
developers vote a package ready to move to "upwards" it should be moved ?  
(assuming that one PUBLISH vote from untrusted developer is enough to get
a package into testing/unstable)

I would really, really like to see this discussed to whatever depth it 
takes and the outcome actually taken into action...

	- Panu -





More information about the devel mailing list