[Bf-committers] Proposal for handling bug reports

Wed Jul 2 08:29:53 CEST 2014

I'm against about automation. Not only because trying to lang it to the
phab code would add extra PITA maintaining the server, but also because it
shouldn't really use some strict rules and use common sense instead.

As for confirmed status -- i dunno. Don't really think it's so much a
hassle to remove "Unconfirmed" project when setting Confirmed status. It's
not about 2 devs being able to reproduce, it's about at least one dev who
able to reproduce, this is enough.

Automation here would be to not use project, but use task priority and a
bit of custom queries.

The thing here is also about, what if some user appears and changes status
to Confirmed? It wouldn't make sense to remove Unconfirmed project because
developers are still unable to reproduce. This is actually more flexible
workflow, we can allow users to review bugs and if they can confirm, they
set the status. Then we see "aha, someone managed to redo, let's talk to
him, maybe it's just matter of sharing startup.blend or so". And once
developer confirmed the report Unconfirmed project gets removed.

@Fazekas László, quite reasonable amount of reports even lacks proper
explanation of what exactly doesn't work :) I mean. i'm not really sure how
to make users to report information we need. Even the button from blender
wouldn't help much if users tends to wipe the template and write own text..

@gandalf3, it's possible to fill in the hash, system info is a bit more
tricky. Adding hash wouldn't increase entropy of our hacks in phab because
we alreayd have custom bugreport form, so guess we can implement this if
others thinks it worth dong.

On Wed, Jul 2, 2014 at 11:48 AM, gandalf3 <zzyxpaw at gmail.com> wrote:

> Would it be possible to make the existing "report a bug" operator in
> /info > help /automatically fill in the hash and system info?
>
> On 07/01/14 22:19, Fazekas László wrote:
> > Many users forget to add even the basic system informations in the bug
> > reports or probably just don't know what to write there.
> >
> > Perhaps the first few rows of the system-info.txt should be a copy-paste
> > part for bug reports, or let's add a new 'bug report to clipboard'
> > function in the help menu which creates a proper form for pasting into
> > the report.
> >
> > 2014-07-02 05:57 keltezéssel, Campbell Barton írta:
> >> Ok, lets see how this goes:
> https://developer.blender.org/project/view/50/
> >>
> >> On Wed, Jul 2, 2014 at 11:37 AM, Campbell Barton <ideasman42 at gmail.com>
> wrote:
> >>> @Jacob Merrill, What your suggesting sounds more like a
> >>> troubleshooting resource, Probably we should have this in our manual -
> >>> list common gotcha's, & solutions. The issue with first reporting
> >>> issues on a forum is users have to report twice and have logins to
> >>> both systems, so wouldnt want to make this the recommended procedure
> >>> for bug reports.
> >>>
> >>>
> >>> @Patrice Bertrand, good point :)
> >>>
> >>>
> >>> @Thomas, I'm a bit wary of automation, mainly because we should use
> >>> common sense when closing reports,
> >>> If someone has a bug on one platform, and 2 people on another fail to
> >>> redo it (the report may not appear to be platform spesific), closing
> >>> automatic wouldn't be any good.
> >>>
> >>> Automatic moving back into the bug tracker when confirmed makes more
> sense.
> >>>
> >>> In practice I don't think moving the reports really going to be a
> >>> bottleneck, if it is, we can check on automating it.
> >>>
> >>>
> >>> On Wed, Jul 2, 2014 at 7:37 AM, Thomas Dinges <blender at dingto.org>
> wrote:
> >>>> I support this. :)
> >>>>
> >>>> Can we automate the process a bit though? Like, if 2 other users can
> confirm the issue, the report becomes „Confirmed“ and part of the regular
> BF-Blender project again, or auto close it, if no one can confirm it in 2
> weeks. Otherwise we also have to regularly check the Blender: Unconfirmed
> project to see if something is new here.
> >>>>
> >>>> Am 01.07.2014 um 20:36 schrieb Campbell Barton <ideasman42 at gmail.com
> >:
> >>>>
> >>>>> Recently we've been getting more bug reports, and its getting to a
> >>>>> point where I don't think we can usefully manage them.
> >>>>> Or, to do so, takes more and more time away from development.
> >>>>>
> >>>>> A lot of the work ends up being communication and many times they
> >>>>> aren't even real bugs.
> >>>>> Just the time to reply to issues, ask user to follow our guidelines
> >>>>> and submit blend files,
> >>>>> asking what version of Blender they use etc...
> >>>>>
> >>>>> Its demotivating to have 100's of reports and try tackle the bug
> tracker,
> >>>>> only to find many reports which are in some unknown status where
> >>>>> nobody can redo the problem or understands what it is.
> >>>>>
> >>>>> Even being more strict and moving issues to TODO, only helps so much.
> >>>>>
> >>>>> So I'd like to do this a bit different:
> >>>>>
> >>>>>
> >>>>> Proposal
> >>>>> ========
> >>>>>
> >>>>> * add "Blender: Unconfirmed" project.
> >>>>>
> >>>>> * If we get a valid bug report but can't redo it, we move immediately
> >>>>> to "Blender: Unconfirmed" with a canned response.
> >>>>>
> >>>>> * 2 other people need to check the report.
> >>>>>
> >>>>> * If after 2 weeks nobody can redo the issue, we close it.
> >>>>>
> >>>>>
> >>>>>
> >>>>> This means users have some more responsibility to have others check
> >>>>> bugs, and redo.
> >>>>>
> >>>>> It does risks closing valid issues sometimes, but at this point we
> >>>>> just have a bugs nobody can redo and nobody replies
> >>>>> to, so they arent useful to have open.
> >>>>> If the bug really happens for others probably it gets reported again
> anyway.
> >>>>>
> >>>>> Of course if a report is incomplete we still mark as incomplete, if
> >>>>> its a TODO, move it,
> >>>>> this is for valid reports which give steps we can follow, but no way
> >>>>> to redo the bug.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Examples
> >>>>> ======
> >>>>>
> >>>>> - https://developer.blender.org/T40881
> >>>>> - https://developer.blender.org/T40877
> >>>>> - https://developer.blender.org/T40870
> >>>>> - https://developer.blender.org/T40864
> >>>>> - https://developer.blender.org/T40858
> >>>>> - https://developer.blender.org/T40838
> >>>>> - https://developer.blender.org/T40788
> >>>>> - https://developer.blender.org/T40787
> >>>>> - https://developer.blender.org/T40784
> >>>>> - https://developer.blender.org/T40753
> >>>>> - https://developer.blender.org/T39591
> >>>>> - https://developer.blender.org/T34962
> >>>>> - https://developer.blender.org/T39467
> >>>>>
> >>>>>
> >>>>> --
> >>>>> - Campbell
> >>>>> _______________________________________________
> >>>>> Bf-committers mailing list
> >>>>> Bf-committers at blender.org
> >>>>> http://lists.blender.org/mailman/listinfo/bf-committers
> >>>> _______________________________________________
> >>>> Bf-committers mailing list
> >>>> Bf-committers at blender.org
> >>>> http://lists.blender.org/mailman/listinfo/bf-committers
> >>>
> >>> --
> >>> - Campbell
> >>
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
>
>
> --
> -gandalf3
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>

-- 
With best regards, Sergey Sharybin