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 <ideasma...@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 <blen...@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 <ideasma...@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@blender.org >>>>> http://lists.blender.org/mailman/listinfo/bf-committers >>>> _______________________________________________ >>>> Bf-committers mailing list >>>> Bf-committers@blender.org >>>> http://lists.blender.org/mailman/listinfo/bf-committers >>> >>> -- >>> - Campbell >> > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers -- -gandalf3 _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
