Open Stack

Bogdan,
I think we should keep bugs open and not "supersed" them by blueprint. I
see following reasons for it.

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.

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.

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.

I don't really see any cons of moving bugs into Won't fix state instead.

Examples of bugs which I would certainly avoid putting into Won't fix:
https://bugs.launchpad.net/bugs/1398817 - disable computes by default
during scale up
https://bugs.launchpad.net/fuel/+bug/1422856 - separate /var & /var/log on
master node

Thanks,

On Wed, Feb 18, 2015 at 8:46 PM, Andrew Woodward <xarses at gmail.com> wrote:

> Bogdan,
>
> 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
>
> On Wed, Feb 18, 2015 at 8:12 AM, Bogdan Dobrelya <bdobrelia at mirantis.com>
> wrote:
>
>> Hello.
>> There is inconsistency in the triage process for Fuel bugs superseded by
>> blueprints.
>> The current approach is to set "won't fix" status for such bugs.
>> But there are some cases we should clarify [0], [1].
>>
>> I vote to not track superseded bugs separately and keep them as "won't
>> fix" but update the status back to "confirmed" in case of regression
>> discovered. And if we want to backport an improvement tracked by a
>> blueprint (just for an exceptional case) let's assign milestones for
>> related bugs.
>>
>> If we want to change the triage rules, let's announce that so the people
>> won't get confused.
>>
>> [0] https://bugs.launchpad.net/fuel/+bug/1383741
>> [1] https://bugs.launchpad.net/fuel/+bug/1422856
>>
>> --
>> Best regards,
>> Bogdan Dobrelya,
>> Skype #bogdando_at_yahoo.com <http://bogdando_at_yahoo.com>
>> Irc #bogdando
>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Andrew
> Mirantis
> Fuel community ambassador
> Ceph community
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Mike Scherbakov
#mihgen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150224/2ad42c99/attachment.html>