<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" target="_blank" style="font-size:12.8000001907349px">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">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"><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 class="h5"><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 class=""><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 class="gmail_signature"><div dir="ltr">Mike Scherbakov<br>#mihgen<br><br></div></div>
</div></div>