fuel-dev team mailing list archive

[Mike Scherbakov <mscherbakov@xxxxxxxxxxxx>]

>  ask bug reporters
we can... but it's unlikely to work.

Instead, I would suggest to follow Task 4 from same OpenStack document -
review incomplete bugs, and move them to Invalid if no info is provided /
can't be reproduced within 2 weeks.


On Tue, Apr 8, 2014 at 1:23 AM, Roman Alekseenkov <ralekseenkov@xxxxxxxxxxxx
> wrote:

> 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
>>
>
>


-- 
Mike Scherbakov
#mihgen