Ubuntu Wiki

   1 [21:30]  * cprofitt says hello
   2 [21:31] <cprofitt> Welcome to Problem Lifecycle in Ubuntu.
   3 [21:31] <cprofitt> Let me introduce myself. I am Charles Profitt and have been an Ubuntu Member since January of 2009 and involved Loco Community.
   4 [21:31] <cprofitt> This session is a result of a UDS-O I led on improving the community involvement with Bugs. That session was focused on the end users, not the developer or QA groups.
   5 [21:31] <cprofitt> In this session I will try to focus this on the developer and QA part of the Ubuntu community. I encourage questions to be asked at any time.
   6 [21:32] <cprofitt> To ask a question, you need to be in #ubuntu-classroom-chat and ask your question in the following format:
   7 [21:32] <cprofitt> QUESTION: <your question here>
   8 [21:32] <cprofitt> note: If you do not begin the line with QUESTION:, ClassBot will not recognize it, and your question will most likely not get answered.
   9 [21:32] <cprofitt> the previous session was on fighting bugs,... but this session will focus on 'problems'
  10 [21:32] <cprofitt> The first thing to remember is that a problem and a bug are not the same. While bugs to cause problems they are not the sole cause.
  11 [21:32] <cprofitt> The next important part is to remember that we have three distinct groups in our community.
  12 [21:33] <cprofitt> 1 - Users
  13 [21:33] <cprofitt> 2 - Technical Users - Systems Administrators or More Advanced Users
  14 [21:33] <cprofitt> 3 - Developers - app developers, packagers, patchers, etc
  15 [21:33] <cprofitt> the users group is and will continue to be the largest group
  16 [21:34] <cprofitt> when Ubuntu started that group was very technical, but as the ease of use has increased the groups has increasingly become composed of less technical users
  17 [21:34] <cprofitt> this is a good thing!!
  18 [21:34] <cprofitt> The final general piece is that bugs are best resolved in development releases and not in stable releases. Once a release is stable there is a much more detailed and stringent process that has to be followed for an update to be released (SRU - Stable Release Update). This is due to the requirement to not cause a cascade of 'bugs'.
  19 [21:34] <cprofitt> This creates a bit of a problem because most, if not all, of the people that fall in the 'users' group will not be running the development release. In fact, many of the technical users will only run the development release on spare equipment.
  20 [21:34] <cprofitt> As our community grows the percentage of Ubuntu users will largely be in the users group and with the developers ending up as the smallest group. To sustain growth it is essential for the entire community to understand the Problem Life Cycle in brief.
  21 [21:35] <cprofitt> Why do I call it the Problem Life Cycle?
  22 [21:35] <cprofitt> Because all bugs start with a problem. A problem might be resolved by a configuration being corrected or it could truly be a bug.
  23 [21:35] <cprofitt> The resolutions of problems start prior to bug reports; bug reporting is for when a problem can be identified as being caused by a bug.
  24 [21:35] <cprofitt> Here is a link to the diagram about the Ubuntu Problem Cycle.
  25 [21:35] <cprofitt> http://ftbeowulf.files.wordpress.com/2011/11/ubuntu-problem2.png
  26 [21:36] <cprofitt> the diagram was just translated this week as well...
  27 [21:36] <cprofitt> and I would appreaciate anyone willing to translate it in to their language
  28 [21:36] <cprofitt> The Ubuntu Community has several resources for users seeking help with a problem; they are:
  29 [21:36] <cprofitt> Ubuntu Forums - ubuntuforums.org
  30 [21:36] <cprofitt> Ask Ubuntu - askubuntu.com
  31 [21:36] <cprofitt> IRC - multiple channels on freenode
  32 [21:36] <cprofitt> Ubuntu Wiki - help.ubuntu.com/community (community) or help.ubuntu.com (official)
  33 [21:37] <cprofitt> Local Community Teams - as my friend Randal says -- boots on the ground
  34 [21:37] <cprofitt> You see this in the first set of boxes in the diagram. If a problem is solved here it is due to a misconfiguration or a mis-understanding of what a piece of software does. I do not consider a work-a-round a solution.
  35 [21:37] <cprofitt> if you are a developer it can help that you are familiar with these areas
  36 [21:37] <cprofitt> it might help expose items that are not bugs, but that are causing users difficulty
  37 [21:37] <cprofitt> for application developers looking to have their applications grow in popularity this can be crucial
  38 [21:38] <cprofitt> You see this in the first set of boxes in the diagram. If a problem is solved here it is due to a misconfiguration or a mis-understanding of what a piece of software does. I do not consider a work-a-round a solution.
  39 [21:38] <cprofitt> If a problem in a stable release is not solved then a user can either wait for the next release or embark on a process that in the past usually ends in frustration for them. That frustration stems from a misperception of the lifecycle.
  40 [21:38] <cprofitt> this misundertanding is important...
  41 [21:39] <cprofitt> and we can not, as a community, respond with phrases like RTFM
  42 [21:39] <cprofitt> regardless of stable or development release; the most important part of bug resolution is in the triage process. Reports must be complete and accurate.
  43 [21:39] <cprofitt> A great resource for reporting bugs can be found here:
  44 [21:39] <cprofitt> https://help.ubuntu.com/community/ReportingBugs
  45 [21:40] <cprofitt> Realize that some bugs are not crashes, but unexpected behavior. As a very simple example imagine a calculator that gave a result of 5 for 2+2. It would not crash, but it would still have a bug that results in unexpected, and inaccurate, results.
  46 [21:40] <cprofitt> For crashes application developers should strive to write error handling code that can provide the end user with meaninful data that can be reported back to the developer.
  47 [21:41] <cprofitt> As a person who supports proprietary sofware in my day job I am very used to errors that tell me nothing more than what I already know --
  48 [21:41] <cprofitt> like -- your app crashed
  49 [21:41] <cprofitt> try to add information that you, as a developer, will need to find the bug
  50 [21:41] <cprofitt> not always easy; I know
  51 [21:42] <cprofitt> On the chart app developers would fall in the 'upstream' category. You should ensure that you have a process for bugs to be filed against your application.
  52 [21:42] <cprofitt> App Developers also have to understand that Ubuntu will not usually push your 'patches' in to a stable release.
  53 [21:42] <cprofitt> If you are involved in bug triage you really need to strive to be friendly and helpful to the user reporting the bug if you wish to keep them engaged. I understand that some reports are a 'waste of time', but take those as an opportunity to help the person reporting the bug learn how to complete better reports.
  54 [21:42] <cprofitt> We also have to understand that waiting for the next release is not a 'bad' thing. Many users are coming from the Microsoft world and are used to new releases being three to five years apart. Remind yourself, and the users, that Ubuntu will put out six releases in a three year period of time. A potential six month wait is a small price to pay for the stability of the release.
  55 [21:43] <cprofitt> so to summarize so far
  56 [21:43] <cprofitt> Users will experience a problem (may or may not be a bug)
  57 [21:43] <cprofitt> they will use any of the several community support resources to seek a solution
  58 [21:43] <cprofitt> the solution could be a configuration change or a work-a-round
  59 [21:44] <cprofitt> after that if their problem is not resolved they may choose to submit a bug report
  60 [21:45] <cprofitt> if that bug report is against a stable release it will have to go through a stringent process before having an SRU update
  61 [21:45] <cprofitt> if it is in a development release the liklihood of getting it fixed is much higher
  62 [21:45] <cprofitt> and the payback for the community that much greater
  63 [21:46] <cprofitt> this process is captured at a high level here:
  64 [21:46] <cprofitt> http://ftbeowulf.files.wordpress.com/2011/11/ubuntu-problem2.png
  65 [21:46] <cprofitt> any questions?
  66 [21:48] <cprofitt> I understand this process has been very abstract...
  67 [21:49] <cprofitt> more of a high level over-view
  68 [21:49] <cprofitt> one thing to keep in mind is some of the potential end points for bugs
  69 [21:50] <cprofitt> when a developer marks a bug 'will not fix' it might be a case of 'can not fix'
  70 [21:50] <ClassBot> There are 10 minutes remaining in the current session.
  71 [21:50] <cprofitt> consider the case of xubuntu which depends on upstream
  72 [21:51] <cprofitt> there may be times when the upstream has decided a specific version is no longer supported
  73 [21:51] <cprofitt> but Ubuntu promises support for an LTS beyond that point
  74 [21:51] <ClassBot> pawel_st_ asked: One of the common complaints about ubuntu bug tracking and fixing is that there are bugs that span multiple releases and don't seem to be taken care of properly (sorry, can't give you an example from top of my head). What would you say to that critique?
  75 [21:52] <cprofitt> properly is potentially a result of not understanding the lifecycle
  76 [21:52] <cprofitt> once the bug is in a stable release it may not get fixed if there is the potential of it causing stability issues
  77 [21:52] <cprofitt> in other cases, like the LTS
  78 [21:53] <cprofitt> upstreams may not be supporting the version of the product included
  79 [21:53] <cprofitt> the other issue is even with +1 or +2 bugs the fix might depend on an upstream developer
  80 [21:54] <cprofitt> this is one area triagers can help
  81 [21:54] <cprofitt> by learning how to report bugs upstream properly
  82 [21:54] <cprofitt> or guiding the reporting end user how to report it upstream
  83 [21:55] <cprofitt> I agree completely that the process can be frustrating when you report a bug and it does not get fixed
  84 [21:55] <ClassBot> There are 5 minutes remaining in the current session.
  85 [21:55] <cprofitt> I have reported bugs for four years and only twice had updates released for my reports
  86 [21:56] <cprofitt> I think the key is really helping bug reporters have proper expectations as to how things get fixed
  87 [21:56] <cprofitt> bugs in an SRU will rarely get fixed
  88 [21:56] <cprofitt> bugs in +1 or +2 that are upstream will only get attention if they go upstream properly
  89 [21:57] <cprofitt> My hope is that we can build a process of ensuring that our entire community has a overview of the process so that they have a reasonable set of expectations
  90 [21:58] <cprofitt> to avoid the 'rage' I see in bug reports on occassion
  91 [21:58] <cprofitt> and to avoid triager and developer burn out
  92 [21:58] <ClassBot> kanliot asked: what is an SRU
  93 [21:58] <cprofitt> and SRU is a Stable Release Update
  94 [21:59] <cprofitt> when a part of the Stable Release gets a patch.... it is called an SRU
  95 [21:59] <cprofitt> thank you to everyone who attended
  96 [21:59] <cprofitt> I hope that this session can spark community discussion about this so we can move forward and manage our communities growth