Sorry, 4 weeks, not 2.
On Tue, Apr 8, 2014 at 1:56 PM, Mike Scherbakov <[email protected]>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 < > [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 > -- 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
