DrinkingFromTheFirehose

Discussion: DrinkingFromTheFirehose/Talk

Summary

In this specification process, we will try to figure out processes how to get on top of the exponentially exploding number of bugs.

Rationale

Bug numbers are climbing. Community members are helping us out and reading every single bug just isn't feasible any more. We need to figure out new approaches to work with our bugs effectively.

Use cases

Sébastien reads all Desktop bugs to try to stay on top of things. This takes him most of his day.

Mike wants to get involved in BugSquashing, but isn't sure where to start or what to do to help out effectively.

Brad wants to optimize views on bugs to make the developer's life easier.

Simon wants to set up a tool to send notifications for certain bugs to certain package maintainers.

Jack has a problem and thinks it's a bug. He logs into launchpad and has to wait for a long time until it turns out that it's not a bug. Jack still has problems and nothing's happening. This is not a great user experience and needs to be addressed. With proper forum integration we could move the bug report to the correct forum section and improve Jack's user experience. UbuntuDemon see ForumIntegration

Average Joe has a problem and goes to the forums. It turns out to be a bug. Now Average Joe has to go to launchpad, register and start telling about his problems again which is scary,confusing and a hassle. UbuntuDemon see ForumIntegration

Devy the Developer discovers a common problem on the forums and comes up with a specification to solve the problem. He creates a thread in the Development Release section of the forums in order to get some specific user feedback on his new spec. UbuntuDemon see ForumIntegration

Toni notices that wlan does not work on his Ubuntu computer. He thinks this is a bug and reports it as such https://bugs.launchpad.net/ubuntu/+bug/85455. He is not expecting a rapid fix, but is hopeful and wants to keep track of the problem. Maybe there will be a fix one day. How ever, the bug is soon rejected. Rejecting makes him feel that his inability to use wlan is not considered a problem by Ubuntu. He comes into conclusion that Ubuntu is not even supposed to be able to access his wlan. He switches to Microsoft Windows and uses wlan happily ever after.

Scope

Design

Implementation

We should have at least four sessions together to

  • identify problems,
  • brainstorm about possible solutions,
  • figure out robust processes to make our lives easier.

[ Comments by Keith Curtis You've got millions of users, a small team, and Linux on the desktop isn't ready in many of your upstreams so this is no surprise. Linux bugs are randomly scattered in the kernel, video & other drivers, nautilus, totem-gstreamer, etc. Therefore, your primary goal should be to get all the bugs filed upstream ASAP when appropriate. It might take 3-18 months for the bug to get fixed, so it is important to get on it quickly, especially as old bugs get stale and people are often no longer able to repro them. Mid June, there are 6500 unconfirmed bugs and its going up by hundreds per week.

I also think that developers should not be fixing this problem. I think that people who file bugs in Ubuntu should also be the ones who shepherd them through the upstream codebases, especially as they are the people who can repro the bug! This is an excellent use of large-scale small investments of community effort. There should be a status for bugs filed upstream. Perhaps some bugs will need an Ubuntu developer involved, but that is just a fraction of the bugs that are out there today. I think if Ubuntu hires a tester, it ought to be someone who figures out how to harness the community in the solving of this problem. I propose something like this: send e-mail to everyone who has an unconfirmed bug and tell them to repro the bug in Dapper, and then if it happens file the bug upstream. If they cannot figure out how to do that, then send an e-mail or go to this web forum to get help. Ian Jackson seems to think that many of the bugs suck, but I think the problem is that the community is still young. I've been a programmer for 16 years and yet even my Ubuntu bugs have had issues. As wikipedia says, don't scare the newbies.

I also think that a tool to send mail to people for bugs which have been in the needs info state for more than 1 week, 1 month, etc. Oftentimes it takes only a gentle reminder to get people to work on things.

All of this allow Ubuntu devs to focus more on writing code which I'm sure they'd rather do.

I see in many cases in the buglist that there are new packages or code upstream for the fix, and some of these comments are many months old. I don't think that Ubuntu is fresh enough, especially as bugs are being fixed in your upstreams at a good clip right now. Doing a UVF too early will mean that you are missing out on tons of new bugfixes. Shipping every 6 months with 3 month old code is a little pointless. I think if you can get it down to 1-2 months, that would be great. Don't forget any regressions can be fixed via your updates mechanism, and in the next release.

The problem with old code isn't just in main, its in MOTU as well. There is a very old Drupal in MOTU; Dapper should have had 4.7 which is a much better version. I don't know if that problem is resources or motivation or skills, but maybe a dev to harness and motivate that effort would be good. MOTU work can be another small investment of many peoples' time, and those people will also get better at contributing to main. MOTU is where new people will start, so make sure you are recruiting and have 1 good webpage with good links to get people going, maybe a virtual conference, etc.

]

Code

Data preservation and migration

Outstanding issues

BoF agenda and discussion

  • Many bug reports are of low quality; sometimes even aggressive interaction with the submitter fails to improve matters. This is discouraging and wasteful of both submitters' and developers' time. We should try to direct most users to support setups rather than bug systems and maybe we should consider making bug reporting tools less visible and less easy-to-use, as well as improving the interface to make it easier to submit good informative and detailed reports. -iwj

  • Everything Ian said, plus automating reporting upstream for trusted triagers, plus improving Launchpad's interface to make processing bug reports more efficient (fewer clicks and page loads). -- MatthewPaulThomas

Comments

At he latest DrinkingFromTheFirehose BOF I heard that Launchpad is going to have a support section instead of integrating or linking to ubuntuforums for support. The reason is probably that they want to have a generic system which also works for non-ubuntu projects. I'm seeing increasing seperation between launchpad and the forums instead of integration. Why duplicate the support effort which ubuntuforums handles well already ? Why re-invent the wheel ? see ForumIntegration , UbuntuDemon

A semi-automated tool for generating bug reports would ease the process of filing bugs, and increase their quality and usefulness. The tool would generate a snapshot of the machine's configuration (from /proc, ldd, dpkg etc.), or perhaps only a subset of this, determined by the executable/package that relates to the bug, and maybe assist in the generation of core dumps. With file versions tracked through the tool, it would be a lot easier to automate the triage of old bugs that have already been fixed upstream. The design of such a tool would need to be sensitive to concerns of security and privacy. How to capture bug information where the system is left unusable also requires consideration.

  • One thing that would be nice from an end-user's perspective is to have the automated bug reporting system offer to install the *-dbgsym package for whatever package is crashing. This makes it easier for non-technical users to provide quality info to developers; and, ends the frustrating process of users submitting empty stack traces to have developers reply, "install the debug package and submit the data". I had to have a kindly Gnome dev explain exactly what I needed to do to be of use to him; and, often developers have neither the time or patience to repeat that spiel to everyone who experiences a crash. Having the automated reporting tool collect a large array of data as suggested above, submitting it to the bug database as above; but, creating a summary report for human readability and quick triage as well. This allows data mining of detailed reports and machined specs possible while making the immediate triage of reports bearable. [This ties in with suggestion below.]

JohnMoser: The semi-automated tool is at AutomatedProblemReports, thanks to pitti and friends. I'm also speccing out AutomatedProblemReportsTagging to help the massive flood of reports be reduced into a form that can be automatically searched, grouped, and organized so that developers can quickly get a list of a bunch of reports that are "likely" to be the same bug. AutomatedProblemReportsTaggingForSecurity was my inspiration for this kind of tagging; I'll probably reduce that to an informational spec.

Michaeljt: See comments added on the talk page.

CategorySpec

DrinkingFromTheFirehose (last edited 2008-08-06 16:19:26 by localhost)