DrinkingFromTheFirehose

Differences between revisions 3 and 4
⇤ ← Revision 3 as of 2006-06-09 17:45:39 →
Size: 3254
Editor: chiark
Comment: support vs bugs
← Revision 4 as of 2006-06-19 07:53:48 → ⇥
Size: 5166
Editor: vsat-148-63-199-59
Comment:
Deletions are marked like this. Additions are marked like this.
Line 35: Line 35:
You've got millions of users, so this is no surprise. No simple way around this problem other than getting more resources. Solutions should be goal driven:
 * All 6000 unconfirmed bugs get confirmed
 * All bugs filed in one or more upstream codebases. Upstreams will fix most of your bugs, but they need to know about them. This should be high priority.
 * Many bugs have fixes in upstream code. Being able to query this state would be good.		 [
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.
Line 40: Line 39:
Recruit help from the community:
 * How many Ubuntu users know C/C++ and could submit patches to the upstreams? Maybe you could create a (virtual?) conference to recruit people with such skills. I think this is hard because understanding even a 20kloc component takes months, but knowing how many Ubuntu users have contributed patches to OSS code before would give you a good sense of this number.
 * Could an Ubuntu community team of be created to take ownership of various areas and be responsible for cleaning up the buglist and making sure bugs quickly get filed upstream? If Ubuntu devs are doing this today, could this be done by the community, freeing up Ubuntu devs for harder stuff?		 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.
Line 44: Line 42:
All distros have lots of bugs. However, Linux on the desktop is gaining momentum, and the upstreams are working hard on fixing bugs (if not, yell at 'em) and will prioritize Ubuntu bugs. 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.

]

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.

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

CategorySpec

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