On Tue, Apr 19, 2011 at 06:59:44AM +1200, Robert Collins wrote: > On Tue, Apr 19, 2011 at 6:42 AM, Bryce Harrington <br...@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 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel