<br><br><div class="gmail_quote">On Tue, Apr 1, 2008 at 5:35 AM, David Mansfield <<a href="mailto:fedora@dm.cobite.com">fedora@dm.cobite.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hey, to extend this 'you can help' thing, is it possible that a<br>
smolt-like setroubleshoot logger could be installed which automatically<br>
(after asking for permission of course) posts the denials to a database<br>
so developers could see statistics, say, after a big batch of updates?<br>
</blockquote><div><br>This is a good idea but....this only helps if people keep selinux in at least permissive.. instead of disabling it completely as part of testing.  Which means its probably not going to help solve whatever weirdness inspired this particular thread.  <br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
I think one thing that's frustrating is to have to open a bugzilla for<br>
each and every one.  It's way too much work.  There needs to be a<br>
specific way to address these 'bogus' denails and get the updated<br>
policies in a streamlined manner, IMHO.</blockquote><div> </div></div>Uhm... you know.. we have a test-list where people can discuss things.. including selinux avc message... with other testers to try to help determine if they are worth filing in bugzilla.<br>
A database of avc messages that can be statically datamined isn't going to magically 'solve' problems. It might show obvious problems, that are easily reproduced...but if they are easily reproduced then the data is somewhat unnecessary.   <br>
<br>What really matters how to catch and correctly resolve issues that are more sporadic in nature, that developers and the internal QA people can't reproduce.    And that takes a commitment for the individual tester who is experiencing the problem to communicate with other human beings as part of a group effort to troubleshoot a subsystem.   If they don't care about the subsystem..fine..then they can choose to disable it and then keep their mouth shut about the problems with. But if they are going to be inspired or frustrated by the problem enough to drag their opinion on to this list that a particular subsystem should be disabled...without first making a sincere effort to participate in the testing of the subsystem...well then..they deserve my scorn for paying lip service to the community testing process. <br>
<br>As a tester, if you what you care about is crap like compiz ui problems, or the fact that your trackpad is fubar'd.. or the fact that keyboard localization doesn't work in gdm....and are putting in the effort to communicate those problems with enough specificity for people to help diagnose and fix it.. then you have earned some credibility to discuss your feelings on the value of those subsystems.  But just because you have done your fair share on testing one subsystem does not give you authority to spout random opinions about the value of other subsystems which you haven't been competently testing...selinux included.  <br>
<br>When testers refuse to discuss the details of problems with at least other testers, the community testing process fails.  This thread is a failure.  The original poster has failed to communicate the problems with enough specificity for anyone to attempt to diagnose it.  Bugzilla be damned. We have a mailinglist for testers, and the original poster clearly knows how to use a mailinglist or else we wouldn't be wasting time on this thread.<br>
<br><br>-jef"I guess its time to resurrect my TestingManifesto page in the wiki"spaleta<br><br>