QA process was Re: RPM submission procedure

[Panu Matilainen]

On Fri, 9 Jan 2004, Michael Schwendt wrote:

> On Thu, 08 Jan 2004 19:56:40 -0600, Timothy John Giese wrote:
> 
> > On the other hand, I feel deterred from reviewing packages.  I am new, 
> > so I am not a "trusted" developer.  In order for a package to be 
> > published, it must be approved by 1 trusted developer or 2 untrusted 
                                                         ^^^^
> > developers. 
> 
> I think it's "OR": 2 untrusted developers OR 1 trusted developer.

That's what Timothy said :)

> 
> > Given the large number of packages and the relatively few 
> > number of reviewers, I feel that my review provides little help in 
> > speeding the overall publication of a package (because I suspect other 
> > untrusted developers are also deterred). 
> 
> We're missing a keyword (or a marker in the summary field) that flags
> package request tickets which have at least one publish vote. Right now,
> your best bet is to sort by "last changed" and visit recently changed
> tickets.

I don't think bugzilla keywords and such are going to help. For any given 
package there are only so many people who a) are interested in it b) are 
willing and capable of doing QA on it. 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. 

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. I've also 
suggested various other schemes to lower the bar of getting 
package into testing/unstable in the "source code audit proposal" thread 
in fedora.us devel list - a thread which unfortunately just died and 
absolutely nothing came out of all the ideas thrown around. Sure, we don't 
want to implement any major systems for fedora.us right now because of the 
looming official Extras merge but some minor tweaks to the policies would 
help, I believe.

	- Panu -