Re: [openstack-dev] [Fuel] tracking bugs superseded by blueprints

2015-02-24 Thread Aleksey Kasatkin
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 mscherba...@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 xar...@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 bdobre...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Fuel] tracking bugs superseded by blueprints

2015-02-23 Thread Mike Scherbakov
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 xar...@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 bdobre...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Fuel] tracking bugs superseded by blueprints

2015-02-18 Thread Andrew Woodward
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 bdobre...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Fuel] tracking bugs superseded by blueprints

2015-02-18 Thread Bogdan Dobrelya
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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev