== Dev Week -- Problem Lifecycle in Ubuntu -- cprofitt -- Thu, 3rd Feb, 2012 == {{{#!irc [21:30] * cprofitt says hello [21:31] Welcome to Problem Lifecycle in Ubuntu. [21:31] Let me introduce myself. I am Charles Profitt and have been an Ubuntu Member since January of 2009 and involved Loco Community. [21:31] 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. [21:31] 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. [21:32] To ask a question, you need to be in #ubuntu-classroom-chat and ask your question in the following format: [21:32] QUESTION: [21:32] note: If you do not begin the line with QUESTION:, ClassBot will not recognize it, and your question will most likely not get answered. [21:32] the previous session was on fighting bugs,... but this session will focus on 'problems' [21:32] 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. [21:32] The next important part is to remember that we have three distinct groups in our community. [21:33] 1 - Users [21:33] 2 - Technical Users - Systems Administrators or More Advanced Users [21:33] 3 - Developers - app developers, packagers, patchers, etc [21:33] the users group is and will continue to be the largest group [21:34] 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 [21:34] this is a good thing!! [21:34] 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'. [21:34] 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. [21:34] 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:35] Why do I call it the Problem Life Cycle? [21:35] Because all bugs start with a problem. A problem might be resolved by a configuration being corrected or it could truly be a bug. [21:35] 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. [21:35] Here is a link to the diagram about the Ubuntu Problem Cycle. [21:35] http://ftbeowulf.files.wordpress.com/2011/11/ubuntu-problem2.png [21:36] the diagram was just translated this week as well... [21:36] and I would appreaciate anyone willing to translate it in to their language [21:36] The Ubuntu Community has several resources for users seeking help with a problem; they are: [21:36] Ubuntu Forums - ubuntuforums.org [21:36] Ask Ubuntu - askubuntu.com [21:36] IRC - multiple channels on freenode [21:36] Ubuntu Wiki - help.ubuntu.com/community (community) or help.ubuntu.com (official) [21:37] Local Community Teams - as my friend Randal says -- boots on the ground [21:37] 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. [21:37] if you are a developer it can help that you are familiar with these areas [21:37] it might help expose items that are not bugs, but that are causing users difficulty [21:37] for application developers looking to have their applications grow in popularity this can be crucial [21:38] 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. [21:38] 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. [21:38] this misundertanding is important... [21:39] and we can not, as a community, respond with phrases like RTFM [21:39] regardless of stable or development release; the most important part of bug resolution is in the triage process. Reports must be complete and accurate. [21:39] A great resource for reporting bugs can be found here: [21:39] https://help.ubuntu.com/community/ReportingBugs [21:40] 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. [21:40] 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. [21:41] 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 -- [21:41] like -- your app crashed [21:41] try to add information that you, as a developer, will need to find the bug [21:41] not always easy; I know [21:42] 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. [21:42] App Developers also have to understand that Ubuntu will not usually push your 'patches' in to a stable release. [21:42] 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. [21:42] 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. [21:43] so to summarize so far [21:43] Users will experience a problem (may or may not be a bug) [21:43] they will use any of the several community support resources to seek a solution [21:43] the solution could be a configuration change or a work-a-round [21:44] after that if their problem is not resolved they may choose to submit a bug report [21:45] if that bug report is against a stable release it will have to go through a stringent process before having an SRU update [21:45] if it is in a development release the liklihood of getting it fixed is much higher [21:45] and the payback for the community that much greater [21:46] this process is captured at a high level here: [21:46] http://ftbeowulf.files.wordpress.com/2011/11/ubuntu-problem2.png [21:46] any questions? [21:48] I understand this process has been very abstract... [21:49] more of a high level over-view [21:49] one thing to keep in mind is some of the potential end points for bugs [21:50] when a developer marks a bug 'will not fix' it might be a case of 'can not fix' [21:50] There are 10 minutes remaining in the current session. [21:50] consider the case of xubuntu which depends on upstream [21:51] there may be times when the upstream has decided a specific version is no longer supported [21:51] but Ubuntu promises support for an LTS beyond that point [21:51] 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? [21:52] properly is potentially a result of not understanding the lifecycle [21:52] once the bug is in a stable release it may not get fixed if there is the potential of it causing stability issues [21:52] in other cases, like the LTS [21:53] upstreams may not be supporting the version of the product included [21:53] the other issue is even with +1 or +2 bugs the fix might depend on an upstream developer [21:54] this is one area triagers can help [21:54] by learning how to report bugs upstream properly [21:54] or guiding the reporting end user how to report it upstream [21:55] I agree completely that the process can be frustrating when you report a bug and it does not get fixed [21:55] There are 5 minutes remaining in the current session. [21:55] I have reported bugs for four years and only twice had updates released for my reports [21:56] I think the key is really helping bug reporters have proper expectations as to how things get fixed [21:56] bugs in an SRU will rarely get fixed [21:56] bugs in +1 or +2 that are upstream will only get attention if they go upstream properly [21:57] 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 [21:58] to avoid the 'rage' I see in bug reports on occassion [21:58] and to avoid triager and developer burn out [21:58] kanliot asked: what is an SRU [21:58] and SRU is a Stable Release Update [21:59] when a part of the Stable Release gets a patch.... it is called an SRU [21:59] thank you to everyone who attended [21:59] I hope that this session can spark community discussion about this so we can move forward and manage our communities growth }}}