Open Stack

I think it is better to keep such bugs open. Please see
https://blueprints.launchpad.net/fuel/+spec/granular-network-functions .
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
https://bugs.launchpad.net/fuel/+bug/1355764 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.



Aleksey Kasatkin


On Tue, Feb 24, 2015 at 12:01 AM, Mike Scherbakov <mscherbakov at mirantis.com>
wrote:

> 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
>
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150224/c057d8ed/attachment.html>