[Bf-committers] Proposal for handling bug reports

Wed Jul 2 14:18:58 CEST 2014

"Would it be possible to make the existing "report a bug" operator in
/info > help /automatically fill in the hash and system info?"

Maybe an item in file menu like "Save for Bug Report" could generate system
info and save it in requested .blend file.
System info would probably be attached more frequently this way.

2014-07-02 8:46 GMT+02:00 Sergey Sharybin <sergey.vfx at gmail.com>:

> It could only work reliably for the official builds, for which we can have
> debug symbols. Otherwise users will need to use blender with debug symbols
> all the time and this bumps blender size by around an order of magnitude.
>
> It's also quite often not enough to know backtrace, it's also needed to
> know how you lead blender to such a state.
>
> Don't tell stacktraces are not helpful, but it's not a magical solution.
>
> P.S. We actually already have a crash text being generated on the crash, It
> helps sometimes to get some clues. Those stacks misses lots of readability
> tho..
>
>
> On Wed, Jul 2, 2014 at 12:38 PM, Jacob Merrill <blueprintrandom1 at gmail.com
> >
> wrote:
>
> > Is it possible to run blender In debug mode, so when a crash happens I
> know
> > what it was doing when it crashes? I could learn a lot that way, and you
> > could crl+printscreen the error
> > On Jul 1, 2014 11:30 PM, "Sergey Sharybin" <sergey.vfx at gmail.com> wrote:
> >
> > > 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
> > > _______________________________________________
> > > 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
> >
>
>
>
> --
> With best regards, Sergey Sharybin
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>