QA process was Re: RPM submission procedure

[Gene C.]

On Friday 09 January 2004 19:22, Michael K. Johnson wrote:
> On Fri, Jan 09, 2004 at 02:42:38PM -0500, Gene C. wrote:
> > I am hopeful that the Red Hat folks will speak on the Fedora Extras
> > subject soon (their lack of comment is very noticeable).  Some of this
> > discussion
>
> Well, I have two reasons for not commenting:
>  o  We don't have the CVS server up yet, and I believe that action
>     should come before talk here.
>  o  I'm doing a lot of listening.  Overall it is important to me that
>     it not be so hard or confusing to do that people don't do it.  I
>     think that the rules can be simple and exceptions worked out on
>     an individual basis; that's what we've done internally.  We need
>     rules, with rationale, better codified -- which is one thing we
>     liked about fedora.us in the first place -- but I think that we
>     need to make sure that people aren't put off too much by the
>     rules we have, and I think that I've got more listening to do
>     before I speak.

Great!  This sounds reasonable.

I am a bit disturbed by some of this discussion and the egos that are 
expressed ... it seems like there is a lot of not-invented-here stuff.  Right 
now I believe that ESR (and the 40 packages he maintains) has been definitely 
alienated by this discussion.

I really like Alex's bleeding/testing/good/stable classification of packages.  
It should be easy to get packages into the bleeding or testing categories but 
to get into either good or stable should require lots more QA.  By QA I mean 
TESTING by lots of people ... not code reviews by a couple of "experts".  My 
experience is that very subtle bugs (or intentional compromises) can fool 
even experts who have access to source code but lots of testing (running the 
software) by lots of people can reveal that the software does have problems 
(even if they cannot point to specific causes).  Your do not get lots of 
testing if the package is not "available".

I am also seeing QA requirements well beyond what Red Hat does internally 
(from my perspective) and what I believe is reasonable.  While I believe that 
some QA rules are needed, lets make them realistic ... lots of rules about 
package format are reasonable but the quality of the code in the package will 
only be discovered through testing (actually running the software).

As I see it, a lot of the Extras (fedora.us) packages are more like the gftp 
package rather than the kernel, gcc, or glibc which need lots of testing 
before becoming stable.  For gftp, Red Hat has taken the software package 
from upstream and then packaged it for Red Hat / Fedora Core making sure that 
it puts stuff into the correct directories, etc.  However, the Red Hat folks 
do not make sure that the software is working as it should ... that is an 
upstream responsibility.  The 2.0.14 version of gftp which is part of FC-1 
has problems with http.  I worked with the upstream maintainer/developer to 
fix these problems and most of the fixes are in 2.0.16 (with the remainder in 
CVS).  While there is no gftp update for FC1, 2.0.16 is available in rawhide 
(development) for those with the need.

IMHO, the objective for Extras should be for a set of packages which do not 
conflict with anything in Core (or other Extras packages) and which have a 
classification which reflects actual user experience with that software.  The 
Extras process should honor and promote this objective.
-- 
Gene