fuel-dev team mailing list archive

[Dmitry Borodaenko <dborodaenko@xxxxxxxxxxxx>]

Roman,

I don't have any problem with moving the bugs from New to Confirmed or
Incomplete states as you describe, I only want to make sure that you
don't change the typical bug state transition sequence from New ->
Confirmed -> Triaged to New -> Triaged -> Confirmed, and don't mandate
moving bugs from New to Confirmed before anyone looked at them and
confirmed that they are valid.

Thanks,
-DmitryB

On Mon, Mar 31, 2014 at 10:51 AM, Roman Alekseenkov
<ralekseenkov@xxxxxxxxxxxx> wrote:
> Dmitry,
>
> My statement was based on:
> https://help.launchpad.net/Bugs/Statuses
>
> What makes you think that the bugs should remain in New state? I'm reading
> the https://wiki.openstack.org/wiki/BugTriage and it seems to be saying the
> opposite:
>
> If the bug description is incomplete or the report is lacking the
> information necessary to reproduce the issue, you should ask the reporter to
> provide missing information, and set the bug status to Incomplete
> If the bug report contains enough information, you can reproduce it (or it
> looks valid), then you should set its status to Confirmed
>
> So, my reading of that is the decision is pretty much binary:
>
> New -> (has enough information / looks valid) -> Confirmed
> New -> (not enough information) -> Incomplete
>
> If Triaged is not an appropriate state, let's use Confirmed. But I really
> want to make sure that the bugs leave New state. This would be nice & clean.
>
> Thanks,
> Roman
>
>
>
> On Mon, Mar 31, 2014 at 10:35 AM, Dmitry Borodaenko
> <dborodaenko@xxxxxxxxxxxx> wrote:
>>
>> Roman,
>>
>> I don't think we should short-circuit triaging bugs like this: Triaged
>> status (according to https://wiki.openstack.org/wiki/BugTriage) means
>> that the solution is at least described in the bug, if not attached in
>> a patch. It's useful to distinguish this state from Confirmed (meaning
>> it can be replicated but root cause is not yet understood) and New
>> (meaning noone tried to replicate it yet). If a bug was assigned and
>> scheduled but hasn't even been confirmed it should remain New.
>>
>> If you are looking to filter untouched bugs, I think the list of bugs
>> assigned to nobody is your best bet. Unfortunately I don't see a way
>> to filter for bugs without a milestone, so it might be difficult to
>> identify assigned but unscheduled bugs. Because of that we should be
>> careful to always set a milestone when processing bugs.
>>
>> My 2c,
>> -DmitryB
>>
>> On Mon, Mar 31, 2014 at 10:10 AM, Roman Alekseenkov
>> <ralekseenkov@xxxxxxxxxxxx> wrote:
>> > Folks,
>> >
>> > I noticed that we are doing good job in processing incoming bugs and
>> > setting
>> > 'Assignee' and 'Milestone' for them. However, the bugs do need to leave
>> > 'New' state when they get assigned to a specific release. The
>> > appropriate
>> > state for issues which are targeted to a particular release would be
>> > 'Triaged'.
>> >
>> > I.e. we should regularly work on cleaning up
>> >
>> > http://fuel-launchpad.mirantis.com/project/fuel/bug_table_for_status/New/None.
>> > Right now it has 32 bug count, and ideally it should be zero.
>> >
>> > Please take an action.
>> >
>> > Thanks,
>> > Roman
>> >
>> > --
>> > Mailing list: https://launchpad.net/~fuel-dev
>> > Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>> > Unsubscribe : https://launchpad.net/~fuel-dev
>> > More help   : https://help.launchpad.net/ListHelp
>> >
>>
>>
>>
>> --
>> Dmitry Borodaenko
>
>



-- 
Dmitry Borodaenko