[Bf-committers] Proposal for handling bug reports

gandalf3 zzyxpaw at gmail.com
Wed Jul 2 07:48:32 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?

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



More information about the Bf-committers mailing list