changing how apport handles master bugs with private data

[Robert Collins]

On Tue, Apr 19, 2011 at 9:54 AM, Bryce Harrington <bryce at canonical.com> wrote:
> 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.

Yes; note that both of these things result in developer time being
consumed: answering questions from users about the situation, about
why they can't view the bug. I spend maybe an hour a week on this at
the moment.

>> >> 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.

Yes.

> This means a developer needs to load and read two bug reports to check
> for comments,

Yes, thats true. This is the case already though - each private
duplicate or sanitised duplicate may get 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).

On a given page, yes.

>> >> 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.

I'm much more worried about UI complexity than implementation
complexity. This can be easy to underestimate :). Implementation
complexity is also a significant overhead too, but UI complexity keeps
charging day in and day out.

> 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.

Well, we could also just create less bugs in the first place. I agree
that time wasted is well, wasted - and that time spent on other things
than fixing bugs doesn't directly fix bugs.

> The proposal on bug #764414 would seek to improve the experience for bug
> reporters, without incurring development effort by Launchpad engineers.

We may need to change launchpad to permit moving bug attachments
around on the back end, for instance. I find the characterisation of
this as avoiding development effort by Launchpad engineers a bit
saddening :(. The long term goal

> 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.

For it to double the quantity of bug reports the following would all
have to be true:
 - all bug reports are filed by apport
 - no bug reports can have their master made public

As for obscuring the attachments, thats already the case for anyone
that is not in bugcontrol; this excludes upstream most of the time,
yet upstream could likely debug and fix problems given the backtrace.

> 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...

Sure; I'd actually like LP to do a callback to the apport backend in
the datacentre for duplicate detection. Right now thats out of reach
though. That said, apport does use a particularly stable summary name
which should get a reasonable match most of the time for crash
reports.

> 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.

If it did that it would remove the support overhead we (both Ubuntu
and Launchpad developers) have at the moment dealing with confused
users. I don't recall why but Martin seemed to dislike doing that.

-Rob