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.