> 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 <[email protected] > 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 > <[email protected]>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 < >> [email protected]> 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 < >>> [email protected]> 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 >>>> <[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 >>> >>> >> >> >> -- >> Mike Scherbakov >> #mihgen >> > > -- Mike Scherbakov #mihgen
-- Mailing list: https://launchpad.net/~fuel-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
