fuel-dev team mailing list archive

[Roman Alekseenkov <ralekseenkov@xxxxxxxxxxxx>]

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
>