On Tue, Apr 19, 2011 at 9:54 AM, Bryce Harrington br...@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
