On Tue, 4 Sep 2012 17:16:57 -0500 C de-Avillez <hgg...@ubuntu.com> wrote:
> On Tue, 4 Sep 2012 18:35:58 +0100 > Phill Whiteside <phi...@ubuntu.com> 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 :-)
signature.asc
Description: PGP signature
-- Ubuntu-qa mailing list Ubuntu-qa@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-qa