Lamar Owen:
So you're talking about something similar to how Slashdot moderation works with points. Then if someone wants to run untested code, they just drop their 'view level' to the appropriate place. If they want solid code, they raise the threshhold and don't see the cruft. In essence, at least. I like >
your idea.
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. If you give people who do NOT know what they are doing, the easy ability, to eat packages that have not be appropriately peer-reviewed...might as well just stop trying to do QA at all...because end-user ASSUME that just because its in an rpm...its worth installing and have no regard for security what so ever. Un-QA'd binaries should not go into a repository. Users who do not know enough to roll their own binaries, should not be expected to self-select what level of codebase is appropriate for them...because frankly that have no real claim to 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.
I think that trusted people should be able to vote negatively too; > a
trusted person might +1 in error occassionally. Or maybe the
trusted person has an interest in seeing a favorite package go through quickly (one would hope not, but facts are facts, and people sometime lose sight of the big picture when their pet idea or package is under fire).
What does marking someone as "trusted" mean then? Trusted people are well.... trusted to do the right thing consistantly. A trusted person earns 'trust' status by showing through multiple and consistent application of the guidelines while untrusted. There is of course going to need to be review and intervention in the 'corner case' of when a trusted person goes postal. But the whole point of deeming someone '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.
-jef"for the sake of signal to noise ratio...and to prevent slipping into a "taste great/less filling" round robin conversation...I'm 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 thread..I have at most one more reply and then I'm not going to reply back in this mailinglist to Owen on this topic. And in the future I will try to follow this guideline as much as possible to avoid getting stuck in long threads that are doing nothing but encouraging people to ignore the list completely. Feel free to ping me off list to remind me if I've stepped over my personal limit in the future"spaleta
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.