fuel-dev team mailing list archive

[Roman Alekseenkov <ralekseenkov@xxxxxxxxxxxx>]

Mike & Team,

Thanks for cleaning up the list of 'New' bugs. That's exactly what I wanted.

In general there shouldn't be any confusion, as "Incomplete" is not a final
state for a bug. If the bugs gets moved to "Incomplete", it means we are
just requesting more information (and not closing the bug). An appropriate
comment should be left by the dev team, so bug reporter doesn't feel
offended.

Instead of us going through the list of 'Incomplete' bugs (manually or
using scripts), may be we should ask bug reporters to move the bugs back to
'New' state after they provide missing information?

Thanks,
Roman


On Sun, Apr 6, 2014 at 2:34 PM, Mike Scherbakov <mscherbakov@xxxxxxxxxxxx>wrote:

> Please, do not reinvent a wheel. If we are following OpenStack procedures,
> then we are following and reusing as much as we can from there.
>
> This thing actually perfectly drops into this category - there is pretty
> good explanation in the community, how to confirm and triage bugs:
> https://wiki.openstack.org/wiki/BugTriage.
>
> However, there are a few things which could be a specific of culture or I
> don't know what, and which are not fully explained on that page:
>
>    1. Sometimes, when we put bug into "Incomplete" state, we do it
>    silently. In the best case, it is with comment "diagnostic snapshot is
>    missing". This is no way to go - if user fails bug, he spends time for it.
>    If someone closes bug as incomplete with such a message, it can be treated
>    as impolite, unprofessional... user will not want to come back and provide
>    more data.
>    If you respect your user, it won't ever happen. For example: "Do you
>    still have this env up? It would be great if you could download diagnostic
>    snapshot from Support page, it should have all the logs required to
>    reproduce the bug.. Thanks!"
>    2. Sometimes, it is obvious from the bug post, that bug is likely to
>    exist with almost 100% of probability. There is no need to even request
>    anything - you can try it out yourself.
>
> I care about bugs in Incomplete state not only because it offend many
> people (I'm personally fine if you close my bug in such a way, but trust me
> - there are many who are not...), but there is one more reason:
> - I suspect we don't reiterate over Incomplete bugs as part of routine
> ops, only on occasion. That's what we should start doing.
>
> Unfortunately, LP doesn't seem to be the best tool to track such things as
> > If the reporter did not answer within 2 weeks:
> - this is from https://wiki.openstack.org/wiki/BugTriage. I believe we
> need a script, or enhance a fuel-launchpad to track such stuff.
>
> If general, if we want to change some flow, ideally we have to introduce a
> corresponding patch to OpenStack community. I am open for further
> discussion, please share your thoughts on the process.
>
> PS.
> Roman, back to your first email - thanks for reminding.
> http://fuel-launchpad.mirantis.com/project/fuel/bug_table_for_status/New/Nonewas cleaned up and now has only 1 bug.
>
> Thanks,
>
>
> On Tue, Apr 1, 2014 at 4:12 AM, Roman Alekseenkov <
> ralekseenkov@xxxxxxxxxxxx> wrote:
>
>> We had an in-person discussion with Dmitry, Andrew in Ryan. No one has
>> objections regarding moving bugs away from 'New' status to 'Confirmed' (if
>> it looks legit), or 'Incomplete' status (if it's lacking info). Let's start
>> doing this.
>>
>> Roman
>>
>>
>> On Mon, Mar 31, 2014 at 11:18 AM, Dmitry Borodaenko <
>> dborodaenko@xxxxxxxxxxxx> wrote:
>>
>>> 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
>>>
>>
>>
>> --
>> 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
>>
>>
>
>
> --
> Mike Scherbakov
> #mihgen
>