# F20 Beta Blocker Review meeting #4 # Date: 2013-10-16 # Time: 16:00 UTC (12:00 EDT, 09:00 PDT) # Location: #fedora-blocker-review on irc.freenode.net
It's blocker review meeting time once more. Yes, yes, you can rejoice, it's finally here!
We'll be running through the final blockers and freeze exception bugs. The current list is available at: http://qa.fedoraproject.org/blockerbugs/current
We'll be reviewing the bugs to determine ...
1. Whether they meet the beta release criteria [1] and should stay on the list 2. Whether they are getting the attention they need
[1] http://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria
For guidance on Blocker and FreezeException bugs, please refer to - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
For the blocker review meeting protocol, see -https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
dlehman proposed https://bugzilla.redhat.com/show_bug.cgi?id=1019500 as a Beta Blocker, and https://bugzilla.redhat.com/show_bug.cgi?id=1019502 as a Final Blocker, but both are private, so they need to be fixed before the meeting.
On Wed, 16 Oct 2013 02:14:55 +0000 (UTC) Andre Robatino robatino@fedoraproject.org wrote:
dlehman proposed https://bugzilla.redhat.com/show_bug.cgi?id=1019500 as a Beta Blocker, and https://bugzilla.redhat.com/show_bug.cgi?id=1019502 as a Final Blocker, but both are private, so they need to be fixed before the meeting.
I've already made those bugs private with the exception of the description on 1019502 - it's still marked as private. I don't see any reason why it's private but figured that I would wait to see if there's a reason and if there is, to request re-filing.
Tim
Unnecessary "private" designation for a bug report might be due to
https://bugzilla.redhat.com/show_bug.cgi?id=1011916
which complains that a bug reporter has to decide about "private" status before possibly sensitive information in the report can be examined.
On 10/16/2013 11:59 AM, Richard Ryniker wrote:
Unnecessary "private" designation for a bug report might be due to
https://bugzilla.redhat.com/show_bug.cgi?id=1011916
which complains that a bug reporter has to decide about "private" status before possibly sensitive information in the report can be examined.
No private information is supposed to be sent over the wire or be harvested by the reporting tool or anything that is automatically filed ( if it does we have a serious problem ) and the reporter is supposed to be responsible for sanitizing his log before submitting them.
JBG
On Wed, 2013-10-16 at 12:50 +0000, "Jóhann B. Guðmundsson" wrote:
On 10/16/2013 11:59 AM, Richard Ryniker wrote:
Unnecessary "private" designation for a bug report might be due to
https://bugzilla.redhat.com/show_bug.cgi?id=1011916
which complains that a bug reporter has to decide about "private" status before possibly sensitive information in the report can be examined.
No private information is supposed to be sent over the wire or be harvested by the reporting tool or anything that is automatically filed
Well, that's kind of impossible. Sometimes a backtrace is going to contain sensitive information. It can't really be any other way. You can't stop a backtrace collection tool from collecting it. You can try to filter it out as best as possible, but you're never going to be 100% accurate.
( if it does we have a serious problem ) and the reporter is supposed to be responsible for sanitizing his log before submitting them.
That's more or less what Richard is talking about. abrt tries to detect if anything in the submitted report might be sensitive (as well as trying to avoid including any expected-to-be-sensitive info whenever possible) and offers to flag the report as private if it thinks so. Not perfect, but better than nothing. There are various issues with its method of doing this which I've reported recently, so it ought to be improving...
Still, this isn't the case we were dealing with here, it was the clone-of-a-private-RHEL-bug thing.
On 10/16/2013 03:08 PM, Adam Williamson wrote:
clone-of-a-private-RHEL-bug thing.
Which is the problem RHEL bugs should not be cloned to to Fedora but the other way around since we are upstream for RHEL.
JBG
On Wed, 2013-10-16 at 15:39 +0000, "Jóhann B. Guðmundsson" wrote:
On 10/16/2013 03:08 PM, Adam Williamson wrote:
clone-of-a-private-RHEL-bug thing.
Which is the problem RHEL bugs should not be cloned to to Fedora but the other way around since we are upstream for RHEL.
Um. That doesn't make sense.
There's a team doing testing of RHEL inside Red Hat. Sometimes they find a bug we haven't found in Fedora. Of course they file it against RHEL as that's what they were testing. If it's then verified to affect Fedora too, it's perfectly reasonable to clone it for Fedora. We can't just tell RHEL testers to file all bugs they find against Fedora then clone them for RHEL - sometimes the bugs won't actually affect Fedora at all.
On 10/16/2013 02:14 AM, Andre Robatino wrote:
dlehman proposedhttps://bugzilla.redhat.com/show_bug.cgi?id=1019500 as a Beta Blocker, andhttps://bugzilla.redhat.com/show_bug.cgi?id=1019502 as a Final Blocker, but both are private, so they need to be fixed before the meeting.
Great yet another broken RH workflow clones of internal RHEL bugs I presume....
JBG
On Wed, 2013-10-16 at 12:41 +0000, "Jóhann B. Guðmundsson" wrote:
On 10/16/2013 02:14 AM, Andre Robatino wrote:
dlehman proposedhttps://bugzilla.redhat.com/show_bug.cgi?id=1019500 as a Beta Blocker, andhttps://bugzilla.redhat.com/show_bug.cgi?id=1019502 as a Final Blocker, but both are private, so they need to be fixed before the meeting.
Great yet another broken RH workflow clones of internal RHEL bugs I presume....
Basically, yeah, people cloned bugs and forgot it'd clone the 'private' property. I don't really see what's 'broken', though - this is a case where it's actually appropriate to use a clone, because there's a whole report already done as a result of RHEL testing, and we want to have that same bug reported for Fedora. They just ought to remember to clear the private flag and make any other appropriate changes.