Re: juju 1.20.0 and future plans.
Well, there is Won't Fix to close them, or there is set them to Low which allows for an acknowledgement that it could be fixed, but just not now. I prefer the Low version myself, as number of Open bugs has never been a concern for me. I do agree that we want a better view of what we are actually going to be working on. I would honestly say I'd love a 1-month/3-month/6-month sort of split, which *would* let us make use of Medium (things to pull from in the next month). Right now, *I* certainly can't keep 294 High bugs in my head to prioritize them into actionable items. Given your numbers, I think we could only *commit in advance* to closing 50 High bugs that are already on the list, because we'll come up with a bunch of other things on our way. We've also been making a bit more use of Launchpad to track features we are completing via tasks tracked as bugs. (We have Kanban, but Kanban linking to bugs is super straightforward, and we can link Branches and MPs, etc off there easily. Linking to work in progress is otherwise pretty clumsy.) Anyway, just to say that 100 bugs fixed is a little inflated over actual things that were known as bugs that we actually fixed. John =:- On Fri, Apr 18, 2014 at 2:38 AM, David Cheney david.che...@canonical.comwrote: Excellent writeup. I agree with your conclusions -- we must reduce the number of open issues, not reclassify them. My vote has always been to close an issue that we cannot realistically fix in the next cycle, but I understand this has always been unpopular. On Fri, Apr 18, 2014 at 5:47 AM, Curtis Hovey-Canonical cur...@canonical.com wrote: NOW I moved a lot of bugs from 1.19.1 to 1.20.0 to make it easier to see out immediate priorities. If we fix a bug in a future milestone I will retarget it to the current goal. The intent is to make is clear what must be fixed verses issues that may be fixed. Their are about 20 issues I *think* need to be resolved that will define 1.19.1 features and fixes. I hope to release 1.19.1 next week. There are about 50 bugs targeted to 1.20.0. This is 2 weeks of bugs. We can expect more bugs as users try the new features. So we are really 3 or more weeks away from 1.20.0 We can anticipate 1.19.2 and 1.19.3, maybe 1.19.4 before .1.20.0 FUTURE We fix about 25 bugs a week. Many bugs are fixed a couple days after we discover them. I think our milestones have a capacity of 20 issue, with room for another 5 added as we fix new bugs. We fixed about 400 bugs in juju-core and its libraries in the last 6 months. That is more than half of all bugs ever fixed in the project. Well done. However, only 100 of those bugs were known when we planned the cycle; 3 out of 4 bugs are fallout from improvements or escalated issues from our past. Developers are reporting many of the fallout bugs a couple days after a merge into trunk. Users report the remaining bugs after a release. Our 6 month cycle capacity is 100 high and critical issues. This a problem for us because there are more than 250 High bugs in Lp. We have 15 months of issues we want to commit to fix soon. We cannot. Our goals change every few months; We, our stakeholders, and our users are misinformed about our priorities and we cannot make plans based on the high bugs. We need to lower the importance of more than half the high bugs to make it clear that some issues will only be fixed by opportunity or assistance. I am aware that we intend to have more engineers in the next cycle, but they will need 3 or months of become competent. We can set no more than 150 bugs as high as stretch goal. Lowering bugs to medium is not helpful. I have years of experience with how projects use bugs in Lp. A medium bug in a large project is not more likely to be fixed than a low bug. Opportunity doesn't discriminate by importance. Bugs classified as medium importance are not likely to be escalated to high in the next cycle. Each cycle with new priorities continues to leap ahead of the medium bugs. If lowering the importance of our bugs is a political problem, we can create a milestone call horizon that has just the bugs we expect to fix in the next 6 months. The unscheduled high bugs will violate the intent of scheduling our commitments. In reality the unscheduled bugs will linger and likely be demoted to Low as interest in them wanes. -- Curtis Hovey Canonical Cloud Development and Operations http://launchpad.net/~sinzui -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
juju 1.20.0 and future plans.
NOW I moved a lot of bugs from 1.19.1 to 1.20.0 to make it easier to see out immediate priorities. If we fix a bug in a future milestone I will retarget it to the current goal. The intent is to make is clear what must be fixed verses issues that may be fixed. Their are about 20 issues I *think* need to be resolved that will define 1.19.1 features and fixes. I hope to release 1.19.1 next week. There are about 50 bugs targeted to 1.20.0. This is 2 weeks of bugs. We can expect more bugs as users try the new features. So we are really 3 or more weeks away from 1.20.0 We can anticipate 1.19.2 and 1.19.3, maybe 1.19.4 before .1.20.0 FUTURE We fix about 25 bugs a week. Many bugs are fixed a couple days after we discover them. I think our milestones have a capacity of 20 issue, with room for another 5 added as we fix new bugs. We fixed about 400 bugs in juju-core and its libraries in the last 6 months. That is more than half of all bugs ever fixed in the project. Well done. However, only 100 of those bugs were known when we planned the cycle; 3 out of 4 bugs are fallout from improvements or escalated issues from our past. Developers are reporting many of the fallout bugs a couple days after a merge into trunk. Users report the remaining bugs after a release. Our 6 month cycle capacity is 100 high and critical issues. This a problem for us because there are more than 250 High bugs in Lp. We have 15 months of issues we want to commit to fix soon. We cannot. Our goals change every few months; We, our stakeholders, and our users are misinformed about our priorities and we cannot make plans based on the high bugs. We need to lower the importance of more than half the high bugs to make it clear that some issues will only be fixed by opportunity or assistance. I am aware that we intend to have more engineers in the next cycle, but they will need 3 or months of become competent. We can set no more than 150 bugs as high as stretch goal. Lowering bugs to medium is not helpful. I have years of experience with how projects use bugs in Lp. A medium bug in a large project is not more likely to be fixed than a low bug. Opportunity doesn't discriminate by importance. Bugs classified as medium importance are not likely to be escalated to high in the next cycle. Each cycle with new priorities continues to leap ahead of the medium bugs. If lowering the importance of our bugs is a political problem, we can create a milestone call horizon that has just the bugs we expect to fix in the next 6 months. The unscheduled high bugs will violate the intent of scheduling our commitments. In reality the unscheduled bugs will linger and likely be demoted to Low as interest in them wanes. -- Curtis Hovey Canonical Cloud Development and Operations http://launchpad.net/~sinzui -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: juju 1.20.0 and future plans.
Excellent writeup. I agree with your conclusions -- we must reduce the number of open issues, not reclassify them. My vote has always been to close an issue that we cannot realistically fix in the next cycle, but I understand this has always been unpopular. On Fri, Apr 18, 2014 at 5:47 AM, Curtis Hovey-Canonical cur...@canonical.com wrote: NOW I moved a lot of bugs from 1.19.1 to 1.20.0 to make it easier to see out immediate priorities. If we fix a bug in a future milestone I will retarget it to the current goal. The intent is to make is clear what must be fixed verses issues that may be fixed. Their are about 20 issues I *think* need to be resolved that will define 1.19.1 features and fixes. I hope to release 1.19.1 next week. There are about 50 bugs targeted to 1.20.0. This is 2 weeks of bugs. We can expect more bugs as users try the new features. So we are really 3 or more weeks away from 1.20.0 We can anticipate 1.19.2 and 1.19.3, maybe 1.19.4 before .1.20.0 FUTURE We fix about 25 bugs a week. Many bugs are fixed a couple days after we discover them. I think our milestones have a capacity of 20 issue, with room for another 5 added as we fix new bugs. We fixed about 400 bugs in juju-core and its libraries in the last 6 months. That is more than half of all bugs ever fixed in the project. Well done. However, only 100 of those bugs were known when we planned the cycle; 3 out of 4 bugs are fallout from improvements or escalated issues from our past. Developers are reporting many of the fallout bugs a couple days after a merge into trunk. Users report the remaining bugs after a release. Our 6 month cycle capacity is 100 high and critical issues. This a problem for us because there are more than 250 High bugs in Lp. We have 15 months of issues we want to commit to fix soon. We cannot. Our goals change every few months; We, our stakeholders, and our users are misinformed about our priorities and we cannot make plans based on the high bugs. We need to lower the importance of more than half the high bugs to make it clear that some issues will only be fixed by opportunity or assistance. I am aware that we intend to have more engineers in the next cycle, but they will need 3 or months of become competent. We can set no more than 150 bugs as high as stretch goal. Lowering bugs to medium is not helpful. I have years of experience with how projects use bugs in Lp. A medium bug in a large project is not more likely to be fixed than a low bug. Opportunity doesn't discriminate by importance. Bugs classified as medium importance are not likely to be escalated to high in the next cycle. Each cycle with new priorities continues to leap ahead of the medium bugs. If lowering the importance of our bugs is a political problem, we can create a milestone call horizon that has just the bugs we expect to fix in the next 6 months. The unscheduled high bugs will violate the intent of scheduling our commitments. In reality the unscheduled bugs will linger and likely be demoted to Low as interest in them wanes. -- Curtis Hovey Canonical Cloud Development and Operations http://launchpad.net/~sinzui -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
