Re: [openstack-dev] [Fuel] Changes in bugs workflow on Launchpad

[Mike Scherbakov]

Dmitry,
I think that #1 is reasonable.
For #2, separate LP projects, I'd want to assess pros/cons before making a
decision. I see more cons at the moment. I've started adding it in the
etherpad, I'd appreciate if other folks would join and provide their input
there.

Thank you,

On Tue, Oct 13, 2015 at 11:34 AM Dmitry Pyzhov  wrote:

> Guys,
>
> I propose several changes in bugs workflow on Launchpad.
> 1) Let's stop using component based team groups as assignees for bugs
> 2) Let's create separate Launchpad projects for qa, docs and infra teams
>
> It will affect everyone who tracks any list of bugs. So I want to be sure
> that everyone can ask question or raise concern.
>
> Why do we need this? We are growing community. In 7.0 release we addressed
> 2153 bugs. This number is almost unmanageable. We have a lot of tags (99
> official and 219 other tags), a lot of Launchpad groups. We have several
> big teams with their own workflows. We have 1482 bugs in our current
> release. In order to understand if a bug in really a bug or some kind of
> support request one have to analyse its tags, assignee and teams of
> assignee. And there is a chance that the analysis will produce wrong result.
>
> I'm trying to make our bug management as clear as possible and produce as
> little extra everyday mouse clicking as possible. Here is list of required
> changes: https://etherpad.openstack.org/p/fuel-bugs-taxonomy
>
> Feel free to ask questions.
> __
> 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-dev] [Fuel] Changes in bugs workflow on Launchpad

[Dmitry Pyzhov]

Guys,

I propose several changes in bugs workflow on Launchpad.
1) Let's stop using component based team groups as assignees for bugs
2) Let's create separate Launchpad projects for qa, docs and infra teams

It will affect everyone who tracks any list of bugs. So I want to be sure
that everyone can ask question or raise concern.

Why do we need this? We are growing community. In 7.0 release we addressed
2153 bugs. This number is almost unmanageable. We have a lot of tags (99
official and 219 other tags), a lot of Launchpad groups. We have several
big teams with their own workflows. We have 1482 bugs in our current
release. In order to understand if a bug in really a bug or some kind of
support request one have to analyse its tags, assignee and teams of
assignee. And there is a chance that the analysis will produce wrong result.

I'm trying to make our bug management as clear as possible and produce as
little extra everyday mouse clicking as possible. Here is list of required
changes: https://etherpad.openstack.org/p/fuel-bugs-taxonomy

Feel free to ask questions.
__
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] Changes in bugs workflow on Launchpad

[Vladimir Kuklin]

Dima

What I think is that we need to somehow group the bugs so that after they
are initially triaged particular component developers can understand which
bugs to get from the pool of unassigned bugs. Could you please show how you
are going to tackle this?

On Tue, Oct 13, 2015 at 11:24 PM, Mike Scherbakov 
wrote:

> Dmitry,
> I think that #1 is reasonable.
> For #2, separate LP projects, I'd want to assess pros/cons before making a
> decision. I see more cons at the moment. I've started adding it in the
> etherpad, I'd appreciate if other folks would join and provide their input
> there.
>
> Thank you,
>
> On Tue, Oct 13, 2015 at 11:34 AM Dmitry Pyzhov 
> wrote:
>
>> Guys,
>>
>> I propose several changes in bugs workflow on Launchpad.
>> 1) Let's stop using component based team groups as assignees for bugs
>> 2) Let's create separate Launchpad projects for qa, docs and infra teams
>>
>> It will affect everyone who tracks any list of bugs. So I want to be sure
>> that everyone can ask question or raise concern.
>>
>> Why do we need this? We are growing community. In 7.0 release we
>> addressed 2153 bugs. This number is almost unmanageable. We have a lot of
>> tags (99 official and 219 other tags), a lot of Launchpad groups. We have
>> several big teams with their own workflows. We have 1482 bugs in our
>> current release. In order to understand if a bug in really a bug or some
>> kind of support request one have to analyse its tags, assignee and teams of
>> assignee. And there is a chance that the analysis will produce wrong result.
>>
>> I'm trying to make our bug management as clear as possible and produce as
>> little extra everyday mouse clicking as possible. Here is list of required
>> changes: https://etherpad.openstack.org/p/fuel-bugs-taxonomy
>>
>> Feel free to ask questions.
>> __
>> 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
>
>


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.com
__
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