lubuntu-qa team mailing list archive

[Phill Whiteside <PhillW@xxxxxxxxxx>]

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