<div dir="ltr">This is great. On the point of:<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-family:arial,sans-serif;font-size:13px">If an Incomplete bug has no response after 30 days it's fair game to<br></span><span style="font-family:arial,sans-serif;font-size:13px">close (Invalid, Opinion, Won't Fix).</span></blockquote><div><br></div><div>How about "Stale" ... since that is where it is. (How hard to add a state?)<br><br><br> </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 19, 2014 at 6:13 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've spent the better part of the last 2 weeks in the Nova bug tracker<br>
to try to turn it into something that doesn't cause people to run away<br>
screaming. I don't remember exactly where we started at open bug count 2<br>
weeks ago (it was north of 1400, with > 200 bugs in new, but it might<br>
have been north of 1600), but as of this email we're at < 1000 open bugs<br>
(I'm counting Fix Committed as closed, even though LP does not), and ~0<br>
new bugs (depending on the time of the day).<br>
<br>
== Philosophy in Triaging ==<br>
<br>
I'm going to lay out the philosophy of triaging I've had, because this<br>
may also set the tone going forward.<br>
<br>
A bug tracker is a tool to help us make a better release. It does not<br>
exist for it's own good, it exists to help. Which means when evaluating<br>
what stays in and what leaves we need to evaluate if any particular<br>
artifact will help us make a better release. But also more importantly<br>
realize that there is a cost for carrying every artifact in the tracker.<br>
Resolving duplicates gets non linearly harder as the number of artifacts<br>
go up. Triaging gets non-linearly hard as the number of artifacts go up.<br>
<br>
With this I was being somewhat pragmatic about closing bugs. An old bug<br>
that is just a stacktrace is typically not useful. An old bug that is a<br>
vague sentence that we should refactor a particular module (with no<br>
specifics on the details) is not useful. A bug reported against a very<br>
old version of OpenStack where the code has changed a lot in the<br>
relevant area, and there aren't responses from the author, is not<br>
useful. Not useful bugs just add debt, and we should get rid of them.<br>
That makes the chance of pulling a random bug off the tracker something<br>
that you could actually look at fixing, instead of mostly just stalling out.<br>
<br>
So I closed a lot of stuff as Invalid / Opinion that fell into those camps.<br>
<br>
== Keeping New Bugs at close to 0 ==<br>
<br>
After driving the bugs in the New state down to zero last week, I found<br>
it's actually pretty easy to keep it at 0.<br>
<br>
We get 10 - 20 new bugs a day in Nova (during a weekday). Of those ~20%<br>
aren't actually a bug, and can be closed immediately. ~30% look like a<br>
bug, but don't have anywhere near enough information in them, and<br>
flipping them to incomplete with questions quickly means we have a real<br>
chance of getting the right info. ~10% are fixable in < 30 minutes worth<br>
of work. And the rest are real bugs, that seem to have enough to dive<br>
into it, and can be triaged into Confirmed, set a priority, and add the<br>
appropriate tags for the area.<br>
<br>
But, more importantly, this means we can filter bug quality on the way<br>
in. And we can also encourage bug reporters that are giving us good<br>
stuff, or even easy stuff, as we respond quickly.<br>
<br>
Recommendation #1: we adopt a 0 new bugs policy to keep this from<br>
getting away from us in the future.<br>
<br>
== Our worse bug reporters are often core reviewers ==<br>
<br>
I'm going to pick on Dan Prince here, mostly because I have a recent<br>
concrete example, however in triaging the bug queue much of the core<br>
team is to blame (including myself).<br>
<br>
<a href="https://bugs.launchpad.net/nova/+bug/1368773" target="_blank">https://bugs.launchpad.net/nova/+bug/1368773</a> is a terrible bug. Also, it<br>
was set incomplete and no response. I'm almost 100% sure it's a dupe of<br>
the multiprocess bug we've been tracking down but it's so terse that you<br>
can't get to the bottom of it.<br>
<br>
There were a ton of 2012 nova bugs that were basically "post it notes".<br>
Oh, "we should refactor this function". Full stop. While those are fine<br>
for personal tracking, their value goes to zero probably 3 months after<br>
they are files, especially if the reporter stops working on the issue at<br>
hand. Nova has plenty of "wouldn't it be great if we... " ideas. I'm not<br>
convinced using bugs for those is useful unless we go and close them out<br>
aggressively if they stall.<br>
<br>
Also, if Nova core can't file a good bug, it's hard to set the example<br>
for others in our community.<br>
<br>
Recommendation #2: hey, Nova core, lets be better about filing the kinds<br>
of bugs we want to see! mkay!<br>
<br>
Recommendation #3: Let's create a tag for "personal work items" or<br>
something for these class of TODOs people are leaving themselves that<br>
make them a ton easier to cull later when they stall and no one else has<br>
enough context to pick them up.<br>
<br>
== Tags ==<br>
<br>
The aggressive tagging that Tracy brought into the project has been<br>
awesome. It definitely helps slice out into better functional areas.<br>
Here is the top of our current official tag list (and bug count):<br>
<br>
95 compute<br>
83 libvirt<br>
74 api<br>
68 vmware<br>
67 network<br>
41 db<br>
40 testing<br>
40 volumes<br>
36 ec2<br>
35 icehouse-backport-potential<br>
32 low-hanging-fruit<br>
31 xenserver<br>
25 ironic<br>
23 hyper-v<br>
16 cells<br>
14 scheduler<br>
12 baremetal<br>
9 ceph<br>
9 security<br>
8 oslo<br>
...<br>
<br>
So, good stuff. However I think we probably want to take a further step<br>
and attempt to get champions for tags. So that tag owners would ensure<br>
their bug list looks sane, and actually spend some time fixing them.<br>
It's pretty clear, for instance, that the ec2 bugs are just piling up,<br>
and very few fixes coming in. Cells seems like it's in the same camp (a<br>
bunch of recent bugs have been cells related, it looks like a lot more<br>
deployments are trying it).<br>
<br>
Probably the most important thing in tag owners would be cleaning up the<br>
bugs in the tag. Realizing that 2 bugs were actually the same bug.<br>
Cleaning up descriptions / titles / etc so that people can move forward<br>
on them.<br>
<br>
Recommendation #4: create tag champions<br>
<br>
== Soft Spots ==<br>
<br>
After looking at probably close to 1000 bugs in 2 weeks I have a<br>
particular impression of soft spots that we have.<br>
<br>
Quotas are kind of a mess. It's not clear that we're even eventually<br>
consistent. There are a lot of bugs about creating servers, deleteing<br>
servers, and leaking quota in the process. I know Jay and Sylvan are<br>
diving hard on the resource tracker right now, I think this should be a<br>
Kilo focus area because it creates terrible confusion and bugs for people.<br>
<br>
EC2 has definitely regressed, especially after block device mapping<br>
changes, to the point that it's not clear it's functional outside of the<br>
most basic server create commands. The EC2 code is largely unchanged<br>
since 2012, and only lightly tested, we need to decide if this is<br>
important or not, and either fix it or delete it. There have been many<br>
past hands going up that said they would help, and then they never do<br>
(you known who you are).<br>
<br>
The VM State machine model is .... Well it's at least suboptimal, but<br>
it's also clear that it's massively leaky, and the way we handle it<br>
internally means we end up in inconsistent wedges all the time. I expect<br>
the complexity here causes a ton of bugs. We need some refactoring to<br>
make things a ton more clear about what's supposed to be happening, and<br>
how to rollback when they go wrong. I think the Tasks work was headed<br>
down that path, but that seems stalled now.<br>
<br>
Cross interaction with Neutron and Cinder remains racey. We are pretty<br>
optimistic on when resources will be available. Even the event interface<br>
with Neutron hasn't fully addressed this. I think a really great Design<br>
Summit session would be Nova + Neutron + Cinder to figure out a shared<br>
architecture to address this. I'd expect this to be at least a double<br>
session.<br>
<br>
Recommendation #5 - 8: we should get on those things :)<br>
<br>
== Triaging Inconsistencies ==<br>
<br>
I found some inconsistencies in how people were triaging bugs, and the<br>
state inconsistencies probably don't help with making the bugs seem<br>
confusing: <a href="https://wiki.openstack.org/wiki/BugTriage" target="_blank">https://wiki.openstack.org/wiki/BugTriage</a> provides some<br>
guideance.<br>
<br>
Importantly:<br>
<br>
Incomplete is an Open state. For bugzilla folks this is NEEDSINFO. I saw<br>
a bunch of 'closing' comments but a move to Incomplete.<br>
<br>
Triaged should be used if the solution to fix the bug is in the bug<br>
itself. Triaged is Confirmed + Solution at enough details to fix it.<br>
<br>
Incomplete bugs should not have assignees or milestones, otherwise it<br>
won't time out.<br>
<br>
== General Cleanup Rules ==<br>
<br>
Here are some general cleanup rules that I was using:<br>
<br>
If an Incomplete bug has no response after 30 days it's fair game to<br>
close (Invalid, Opinion, Won't Fix).<br>
<br>
If a bug is In Progress with no patch posted after 30 days, it is not In<br>
Progress. Remove assignee, move back to last state (probably confirmed).<br>
Move to Opinion if it's really a "post it note".<br>
<br>
If a bug is In Progress but the patches were abandoned, it's no longer<br>
In Progress. Remove assignee, move back to last state (probably<br>
confirmed). Move to Opinion if it's really a "post it note".<br>
<br>
== Rescuing Stalled Fixes ==<br>
<br>
Over the course of this I found a bunch of the In Progress bugs were<br>
real issues, with real fixes, that had stalled out for one of a number<br>
of reasons. Often it had a -1 'needs unit tests' on it, and it's sort of<br>
clear the author didn't really know how to do that for this patch. Other<br>
times the author's first language was not english, and the patch commit<br>
message was confusing enough that no one understood what it was fixing.<br>
(One of these bugs I restored, rewrote the commit message, and then it<br>
sailed through the process.)<br>
<br>
Recommendation #9: if you are going to -1 for unit tests, please go the<br>
extra step of saying 'I think you should write a test that does X, Y, Z'.<br>
<br>
Recommendation #10: We need to find a better balance in rewriting commit<br>
messages. Maybe we should just make it socially acceptable to rewrite<br>
the commit message as part of review.<br>
<br>
....<br>
<br>
I'm sure there are other thoughts, but my brain is running out of steam.<br>
These were the things that popped to the top of my head. It's definitely<br>
been really interesting to spend this much time with the tracker to<br>
build a bigger picture of this feedback channel we have from our users.<br>
Hopefully other folks found some of this handy.<br>
<span class="HOEnZb"><font color="#888888"><br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br></div>