fuel-dev team mailing list archive

[Mike Scherbakov <mscherbakov@xxxxxxxxxxxx>]

Sorry, 4 weeks, not 2.


On Tue, Apr 8, 2014 at 1:56 PM, Mike Scherbakov <mscherbakov@xxxxxxxxxxxx>wrote:

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



-- 
Mike Scherbakov
#mihgen