QA process was Re: RPM submission procedure
Lamar Owen
lowen at pari.edu
Fri Jan 9 18:05:13 UTC 2004
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
More information about the devel
mailing list