changing how apport handles master bugs with private data

[Bryce Harrington]

On Tue, Apr 19, 2011 at 06:59:44AM +1200, Robert Collins wrote:
> On Tue, Apr 19, 2011 at 6:42 AM, Bryce Harrington <bryce at canonical.com> wrote:
> > On Mon, Apr 18, 2011 at 09:53:56PM +1200, Robert Collins wrote:
> >> https://bugs.launchpad.net/ubuntu/+source/apport/+bug/764414
> >> has a summary in it of a chat pitti and I had on IRC about the
> >> handling of master bugs with private data. What we currently do
> >> consistently confuses users and prevents Launchpads duplicate bug
> >> detection working properly (because the master bug cannot be seen).

>From the bug report, the two issues this aims to solve are:

1.  When new bugs are filed, LP doesn't show private bugs that may be
    dupes.
2.  After filing, apport sometimes marks bugs as dupes of a master
    private bug, which the dupee can't view.

> >> The basic proposal is:
> >>  - the master bug should be a public bug
> >>  - there should be a link in the description for easy access by
> >> developers to a private-master which has the confidential data
> >> [crashdumps etc]
> >>  - apport should do this automatically.

>From the bug report, there are two implementation alternatives
suggested, each of which has a noteable trade off:

A.  Public master bug filed by apport.  Trade-off is all crash bugs
    appear to be filed by apport.

B.  Private bug filed by apport.  Trade-off is that apport will move all
    the files off the public bug to the private one.

Further, both alternatives have the additional trade-off that there are
two bug reports filed for each crash bug.

This means a developer needs to load and read two bug reports to check
for comments, and that when looking at listings of bug reports fewer
bugs will be shown (since some portion will be the private portions of
the master bug reports).

> >> More details in the linked bug; we'd appreciate any
> >> concerns/feedback/improvements folk can offer.
> >
> > Sounds overly complicated.  Why not just set the crash dump attachment
> > as private?
> 
> Privacy is set on bugs not attachments; setting it directly on
> attachments would entail considerable complexity.

Despite the implementation complexity outlined that would occur on
the launchpad side, it still appears to be the simpler solution on the
package maintainer side.

>From what I can see, the main problem we should aim to solve is to get
the reported bugs *fixed*.  That is obviously the best way to stop the
deluge of duplicate reports.  To that end, we should look for solutions
which increase the amount of time package maintainers have to fix bugs.

The proposal on bug #764414 would seek to improve the experience for bug
reporters, without incurring development effort by Launchpad engineers.
However, the trade offs would hinder work by package maintainers.  It
would double the quantity of bug reports they need to manage, and either
obscure the reporter's name or obscure the attachments.


Having handled a quantity of apport crash reports myself, here are my
thoughts on the two original issues:


1.  When new bugs are filed, LP doesn't show private bugs that may be
    dupes.

For this class of bug where we have tangible data (crash stacktraces or
gpu dumps or the like), users tend to be less reliable determiners of
whether a bug is a dupe.  It is better to have apport or a triager or
package maintainer make the judgment call.

So, while decreasing the number of dupe bug reports filed does have some
tangible value, in this particular case of having the users try to
decide duplication, the value is comparatively low.

Now, when there are a humongous number of dupe crash bugs filed, this
value can add up; however invariably some portion of these bug reports
will be set as public.  So, even in this case it's better to limit the
display to the bug reporter to just the publically visible bugs.

If a developer or triager is actively maintaining the package, then it's
likely the public bug reports are the ones being actively worked.  If no
one is actively maintaining the package, well that's an entirely
different problem...

2.  After filing, apport sometimes marks bugs as dupes of a master
    private bug, which the dupee can't view.

This does sound like an annoying problem.  In practice I've not seen
this happen that much.  However, it seems like it could be more easily
fixed by just having apport check if the would-be master is private and
if so, skip duping against it and instead look for public instances.

Bryce