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 <[email protected]> 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 > <[email protected]> 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 >> <[email protected]> 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 : [email protected] >> > 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 : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
