On Fri, Nov 27, 2020 at 06:05:41PM +0100, Peter Krempa wrote: > On Fri, Nov 27, 2020 at 16:50:01 +0000, Daniel Berrange wrote: > > On Fri, Nov 27, 2020 at 04:15:44PM +0100, Peter Krempa wrote: > > > On Thu, Nov 26, 2020 at 19:51:53 +0000, Daniel Berrange wrote: > > > > On Thu, Nov 26, 2020 at 02:23:17PM +0100, Peter Krempa wrote: > > [...] > > > > I can try to send a cut-down version, which will have only single-line > > > comments with the suggestions, but I still think that we are better off > > > having the request for data in the body of the bugreport than sending > > > them to some documentation elsewhere. > > > > I pushed an example of a simpler template that is much more like the > > view you get when using Bugzilla: > > > > https://gitlab.com/berrange/libvirt/-/issues/new > > > > https://gitlab.com/berrange/libvirt/-/commit/faf1aee60675604a04cbe2e2441dcad233963b86 > > > > IMHO, this kind of simpler template is less intimidating and clearer > > as to what information to provide. > > I'm missing a section or hint to upload XMLs and logs if approrpiate. > In many cases users will just post the error and don't add any relevant > information. When later asked they won't be able to produce them as > they've torn down the setup. > > Also given the amount of already fixed bugs I'd add a hint to try to > test it on latest version, but I'm not as keen on having this one as the > previous one. Both of the proposals are improvement compared to the current situation. I guess for the new_feature template there is nothing to discuss. I guess we can remove the <!-- Note: ... --> comment. It's not necessary to have it in the template and if users remove the other comments before submitting the issue it will do no harm as well. For the qemu bug report I'm not so sure about having separate template for QEMU, I don't see that much value in having it and it might confuse users or users of other hypervisors might start asking for adding a template for them as well. The generic bug report I would go for something in between the two proposals. The one from Peter has a lot of comments at the beginning which might be confusing for the users and they can get easily lost in the template. The one from Dan is missing additional details like XML of the VM or device, debug logs or any logs. When I was discussing this with Peter I suggested using some command examples on how to get the specific details but looking into it right now it is mostly not necessary. The only place where it could help would be to describe how to enable debug logs but that would make the template way too long and probably confusing for the users because enabling debug logs is not that trivial and there are some caveats described in the document like returning back to the original logging settings and the difference between runtime and persistent setting and so on. Taking both proposals for the template I would go with something like this: ------------------------------------------------------------------------ <!-- See https://libvirt.org/bugs.html#quality for guidance --> ## Software environment - Operating system: - Architecture: - kernel version: - libvirt version: - Hypervisor and version: ## Description of problem ## Steps to reproduce 1. 2. 3. ## Expected behavior ## Additional information <!-- Please provide additional details. This list is not complete and contains what we usually ask the reporter if missing: - XML configuration of VMs or other objects - log files (please attach compressed archive if you can't find the relevant section) - stack trace of the crashed binary See https://libvirt.org/kbase/debuglogs.html for details how to configure debug logs. <!-- The line below ensures that proper tags are added to the issue. -- > /label ~bug ------------------------------------------------------------------------ I've added a kernel version line and the additional info section. All of this combines the ideas from Peter and Dan. Pavel
Attachment:
signature.asc
Description: PGP signature
