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
