<div dir="ltr"><div><br></div><br><div class="gmail_extra"><br><div class="gmail_quote">On 4 December 2015 at 00:44, Oleg Bondarev <span dir="ltr"><<a href="mailto:obondarev@mirantis.com" target="_blank">obondarev@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Thu, Dec 3, 2015 at 10:06 PM, Vasudevan, Swaminathan (PNB Roseville) <span dir="ltr"><<a href="mailto:swaminathan.vasudevan@hpe.com" target="_blank">swaminathan.vasudevan@hpe.com</a>></span> wrote:<br><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">Hi Carl,<br>
Sounds reasonable suggestion.<br>
Thanks<br>
Swami<br>
<div><div><br>
-----Original Message-----<br>
From: Carl Baldwin [mailto:<a href="mailto:carl@ecbaldwin.net" target="_blank">carl@ecbaldwin.net</a>]<br>
Sent: Thursday, December 03, 2015 10:47 AM<br>
To: OpenStack Development Mailing List<br>
Subject: [openstack-dev] [Neutron][DVR]<br>
<br>
I was going to bring this up in the meeting this morning but IRC troubles prevented it.<br>
<br>
After chatting with Armando, I'd like to suggest a few enhancements to how we're tackling DVR during this cycle. I'm hoping that these changes help us to get things done faster and more efficiently. Let me know if you think otherwise.<br>
<br>
First, I'd like to suggest adding DvrImpact to the comment of any patches that are meant to improve DVR in some way. People have asked me about reviewing DVR changes. I can show them the DVR backlog [1] in launchpad but it would be nice to have a DVR specific dashboard.<br>
With DvrImpact in the subject, we can make it even more convenient to find reviews.<br></div></div></blockquote><div><br></div></span><div>+1</div><span class=""><div> </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"><div><div>
<br>
The other change I'd like to propose is to categorize our DVR backlog in to three categories: broken, scale (loadimpact), and new features.<br>
I'd propose that we prioritize in that order. Anyone have any suggestions for how to tag or otherwise categorize and tackle these?<br></div></div></blockquote><div><br></div></span><div>This might be useful but honestly I don't feel a strong need for categorizing dvr bugs at the moment because of the amount of bugs (currently I see 31 when filtering by l3-dvr-backlog tag).</div><div>l3-dvr-backlog tag + High/Critical may stand for 'broken', l3-dvr-backlog + loadimpact for 'scale', l3-dvr-backlog + Wishlist for new (small) enhancements.</div><div>I might be missing something though.</div></div></div></div></blockquote><div><br></div><div>That's a good point:</div><div><br></div><div>* High/Critical ==> DVR doesn't do what it's supposed to do</div><div>* LoadImpact ==> DVR doesn't break but it takes forever to complete</div><div>* Wishlist ==> DVR doesn't do this, but it'd be nice if it did</div><div><br></div><div>My suggestion was not so much to add an extra layer of classification, but to figure out how to prioritize review/coding efforts of bugs in these categories in a way so that each area sees progress at a similar rate. Easier said than done :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </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"><div><div>
I know there is a loadimpact (or similar) tag those. Should we come up with a couple more tags to divide the rest?<br>
<br>
Thoughts?<br>
<br>
Carl<br>
<br>
[1] <a href="https://goo.gl/M5SwfS" rel="noreferrer" target="_blank">https://goo.gl/M5SwfS</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></span></div><br></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>