QA process was Re: RPM submission procedure

[Lamar Owen]

On Friday 09 January 2004 12:14 pm, Jef Spaleta wrote:
> No absolutely not...we aren't talking about crufty comments we are
> talking about QA..QA that impacts security of the codebase. I am a FIRM
> believer that end-users do not care enough about security and its up to
> the development side to do the correct amount of caring.

Developers and testers are just different types of end-users, in one way of 
looking at things.  If you know enough to see the cruft (and I label that as 
anything that isn't 'golden' and full QA'd), then you see it, test it, and 
help out.  I like the way Axel has ATrpms set up in this way; I can see very 
clearly what package is where, and it is obvious that I should install some 
packages on production boxes, but I am welcome to test the others.  Or help 
develop in the case of bleeding.  But I like that sort of transparency where 
the assumption is that the user knows what they are doing, and that you don't 
second-guess them.  That is a perfect extension of the Unix philosophy. No 
handholding if you want that.  ATrpms way isn't necessarily for the faint of 
heart, and it's not the only way to do things, as fedora.us proves.  But it 
works for me.  But both ways work for me, since the end result is a good 
package.

> If you give people who do NOT know what they are doing, the easy
> ability, to eat packages that have not be appropriately

This is fedora-devel.  When using the second person plural pronoun 'you' in 
the context of this list one is referring to the community of developers, not 
endusers.  So when I say 'you can choose to see whatever' I mean the 
community of developers, not endusers.  End users can become developers and 
testers; that is the open source way.  But they don't have to.  But this 
audience in this list doesn't need protection from  themselves, and might 
want to have transparent easy access to prebuilt packages.  I think fedora.us 
does something fairly similar, just different details.  But the details don't 
matter as much as being able to have reliable peer review; that is the key 
point you make, and one I agree with.

> understanding what is appropriate. User who are infused with clue...can
> follow-up on the transparent QA bugticket...find the src.rpm listed that
> needs review and roll their own and be a part of the QA effort.

Being-able-to-QA-the-package != being-able-to-rebuild-the-package.  Sometimes 
the person who makes a good package builder woudn't make a good package 
tester.

> What does marking someone as "trusted" mean then? Trusted people are
> well.... trusted to do the right thing consistantly. 

Then no one is trusted, since everyone makes mistakes.

> to need to be review and intervention in the 'corner case' of when a
> trusted person goes postal.

Mistakes != going postal.

> 'trusted' is to...trust them. It should be pretty clear from the way
> people interact on on QA bugtickets about whether they 'get it' and are
> following the guidelines and allowing for reasonable discussion about
> the technical merits of the packaging before marking something publish.

And who applies the label of trust?  Trusted people?  The whole concept of 
trust is pretty basic to this, and, IMO, trust should, like you said, be 
earned.

In the Slashdot case, everybody gets a shot at moderation on a semi-random 
basis.  But, you are right in that a discussion board moderation scheme makes 
at best an unweildy analogy.

> implementing a 2 post personal limit on my replies to people in a
> thread. So in this case this counts as my first reply to Owen in this

Jef, this is a good idea, and is good netiquette to boot.  As for me, I really 
don't have anything more to add on this point, so that's it for me.  It's a 
very minor point.  And you may feel free to call me Lamar.
-- 
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu