lubuntu-qa team mailing list archive

[Greg Faith <gregfaith@xxxxxxxxx>]

On Tue, Sep 4, 2012 at 4:30 PM, Phill Whiteside <PhillW@xxxxxxxxxx> wrote:
>
> Hi,
>
> as requested on my visit to #ubuntu-bugs I have added the following [1]
> Please feel free to edit it. Testers just want a quick answer to an issue
> whereby their bug 'dis-appears'.
>
> Thanks,
>
> Phill.
> 1. https://wiki.ubuntu.com/QATeam/Overview#My_Bug_went_Private
>
> On 4 September 2012 23:18, C de-Avillez <hggdh2@xxxxxxxxxx> wrote:
>>
>> On Tue, 4 Sep 2012 17:16:57 -0500
>> C de-Avillez <hggdh2@xxxxxxxxxx> wrote:
>>
>> > On Tue, 4 Sep 2012 18:35:58 +0100
>> > Phill Whiteside <PhillW@xxxxxxxxxx> wrote:
>> >
>> > > Hi folks,
>> > >
>> > > recently a bug reported by a QA member was marked as a duplicate (no
>> > > harm there), but the 'master' bug was set as 'private'. This meant
>> > > that the person who registered it could not access it to view /
>> > > update etc.
>> > >
>> > > I had a chat with the bug squad about this. If this happens they ask
>> > > that you go to #ubuntu-bugs and raise it with them. The bot does go
>> > > trawling for duplicated bugs, but it is not aware if the bug it is
>> > > using as master is private. I'll get the wiki area updated.
>> >
>> > To expand a bit more on it: there are two major types of private bugs:
>> >
>> > (this is centered on Ubuntu, but should be similar on other projects,
>> > like Lubuntu)
>> >
>> >  * born private (usually security and apport crashdump bugs)
>> >  * made private later on.
>> >
>> > The apport crashdumps are born private because they carry a coredump
>> > file -- and it can carry a LOT of private data in it. Additionally,
>> > apport processing runs a GDB 'bt full' for both the offending thread
>> > (the one that got hit) and for all threads. The 'bt full' sports
>> > variable assignment values. Depending on the program, and where it got
>> > hit, these variables values could also hold private data. No matter
>> > what, at the end of apport processing, the coredump is deleted.
>> >
>> > So... apport will, usually, not make a crashdump bug public. But it
>> > knows about it, and will match as needed, marking newer bugs as
>> > duplicates.
>> >
>> > A subset of Launchpad users have access to these bugs, and can
>> > manually review and decide on an action -- the worst scenario is we
>> > see private data, and will have to discuss with someone else (a
>> > maintainer/developer of the package) if the private data is critical;
>> > if it is not, we can edit/remove the offending pieces, and make the
>> > bug public. If it is, on the other hand, there is not much we can do.
>> > But these are very unusual cases, I do not remember seeing one myself.
>> >
>> > So, to summarise: yes, your bug can be dupped to a private bug. In
>> > this case, please pop in #ubuntu-bugs, or email Bug
>> > Control/Ubuntu-QA, and ask for someone to perform the check. We will
>> > be happy to help.
>> >
>> > It is just that there are more bugs than the time we have...
>>
>> Darn, forgot the most important piece: Thank you, Phil, for pinging us
>> and taking the lead on making this public :-)
>>
>
>
>
> --
> https://wiki.ubuntu.com/phillw
>
> --
> Mailing list: https://launchpad.net/~lubuntu-qa
> Post to     : lubuntu-qa@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~lubuntu-qa
> More help   : https://help.launchpad.net/ListHelp
>

You guys are getting it done without any nagging. I can assure you
there are others who have had this happen to them and now we have a
defined route to resolution.

Thanks,
Greg Faith (nm_geo)