<div dir="ltr">I think it is better to keep such bugs open. Please see <a href="https://blueprints.launchpad.net/fuel/+spec/granular-network-functions">https://blueprints.launchpad.net/fuel/+spec/granular-network-functions</a> . There are some related bugs here. One is fixed, another one is in progress, two are closed. If bug is strictly coherent with blueprint (like <a href="https://bugs.launchpad.net/fuel/+bug/1355764">https://bugs.launchpad.net/fuel/+bug/1355764</a> for this BP) is can be closed almost without doubt. But some of them can be solved separately somehow or have workarounds. Sometimes scope of BP can be changed (e.g. split to several BPs) or its timeline is changed so bugs should not be lost without care.<div><br><div><br></div></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">Aleksey Kasatkin
<br><br></div></div></div>
<br><div class="gmail_quote">On Tue, Feb 24, 2015 at 12:01 AM, Mike Scherbakov <span dir="ltr"><<a href="mailto:mscherbakov@mirantis.com" target="_blank">mscherbakov@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">Bogdan,<div>I think we should keep bugs open and not "<span style="color:rgb(80,0,80);font-size:12.8000001907349px">supersed</span>" them by blueprint. I see following reasons for it. </div><div><br></div><div>Often, we can find workaround in order to fix the bug. Even if bug naturally seems to be falling into some blueprint's scope. Then problem is that when you close the bug, you don't even try to think about workaround - and project gets shipped with some serious gaps from release to release.</div><div><br></div><div>Another issue is that you lose real technical requirements for blueprints. If you keep bugs open and associated with blueprint, you will pass by bugs a few times before you deliver blueprint's functionality, and finally close bugs if code covers bug's case. At least, I'd like it to be so.</div><div><br></div><div>Finally, QA and users will keep opening duplicates, as no one will be happy with won't fix. You can vote for bug (by "affecting" it), and you can't for blueprint in LP, unfortunately. This just keeps door open for getting feedback.</div><div><br></div><div>I don't really see any cons of moving bugs into Won't fix state instead.</div><div><br></div><div>Examples of bugs which I would certainly avoid putting into Won't fix:</div><div><a href="https://bugs.launchpad.net/bugs/1398817" style="font-size:12.8000001907349px" target="_blank">https://bugs.launchpad.net/bugs/1398817</a> - disable computes by default during scale up<br></div><div><a href="https://bugs.launchpad.net/fuel/+bug/1422856" target="_blank">https://bugs.launchpad.net/fuel/+bug/1422856</a> - separate /var & /var/log on master node</div><div><br></div><div>Thanks,</div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Wed, Feb 18, 2015 at 8:46 PM, Andrew Woodward <span dir="ltr"><<a href="mailto:xarses@gmail.com" target="_blank">xarses@gmail.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"><div dir="ltr">Bogdan,<div><br></div><div>Yes I think tracking the bugs like this would be beneficial. We should also link them from the BP so that the imperilmenter can track them. It adds "related blueprints" in the bottom of the right column under the subscribers so we probably should also edit the description so that the data is easy to see </div></div><div class="gmail_extra"><div><div><br><div class="gmail_quote">On Wed, Feb 18, 2015 at 8:12 AM, Bogdan Dobrelya <span dir="ltr"><<a href="mailto:bdobrelia@mirantis.com" target="_blank">bdobrelia@mirantis.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">Hello.<br>
There is inconsistency in the triage process for Fuel bugs superseded by<br>
blueprints.<br>
The current approach is to set "won't fix" status for such bugs.<br>
But there are some cases we should clarify [0], [1].<br>
<br>
I vote to not track superseded bugs separately and keep them as "won't<br>
fix" but update the status back to "confirmed" in case of regression<br>
discovered. And if we want to backport an improvement tracked by a<br>
blueprint (just for an exceptional case) let's assign milestones for<br>
related bugs.<br>
<br>
If we want to change the triage rules, let's announce that so the people<br>
won't get confused.<br>
<br>
[0] <a href="https://bugs.launchpad.net/fuel/+bug/1383741" target="_blank">https://bugs.launchpad.net/fuel/+bug/1383741</a><br>
[1] <a href="https://bugs.launchpad.net/fuel/+bug/1422856" target="_blank">https://bugs.launchpad.net/fuel/+bug/1422856</a><br>
<br>
--<br>
Best regards,<br>
Bogdan Dobrelya,<br>
Skype #<a href="http://bogdando_at_yahoo.com" target="_blank">bogdando_at_yahoo.com</a> <<a href="http://bogdando_at_yahoo.com" target="_blank">http://bogdando_at_yahoo.com</a>><br>
Irc #bogdando<br>
<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br><div>Andrew<br>Mirantis<br>Fuel community ambassador <br>Ceph community</div>
</font></span></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br></div></div><span class="HOEnZb"><font color="#888888"><div><div dir="ltr">Mike Scherbakov<br>#mihgen<br><br></div></div>
</font></span></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" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
<br></blockquote></div><br></div>