On Fri, 16 Sep 2016 17:19:24 +0000 Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > Automatically? If I receive a bug upstream, I want to receive it > without the distribution's embellishments: I want to know what > *upstream* version of the software was used, how I can reproduce the > bug using generic installation from sources, and not using the distro > package, etc. Also, I don't want to read the full history on the > distribution bugtracker, I want to see a concise summary of > findings. I want to see an explanation why the bug is an upstream bug, > not a distro-specific thing. The person who is forwarding bugs has to > all of this by hand, and doing this automatically is infeasible. You don't want much, do you? :-) A person who can do what you require might as well fix the bug, because they have to know the application almost as well as a developer. (I understand that this an exaggeration, hyperbole, but there is some truth to it also.) 'what upstream version' The version of the problem software is easy to pull out of the src.rpm. 'reproduce the bug using generic installation from sources' The environment where the software runs is *part* of the bug. If the software can't deal with various environments properly, that's a bug in the software. Is upstream saying, our software only works in generic environments and we don't guarantee it, or fix it, anywhere else? If so, they should explicitly state that, or their development environment, and disclaim any other usage. This might make sense if I'm Joe Blow, and I'm running my custom distribution, but for Fedora, Ubuntu, Suse, Debian, Arch, Gentoo, where there are standardization processes? I don't think so. The software resources and scope also matters. If I've created a small app to display some proc variables by myself, with a single computer, that's a different situation than a program like gcc or gnome or kde. 'want to see a concise summary of findings' 'want to see an explanation why the bug is an upstream bug, not a distro-specific' If I'm killing flies or mosquitoes, I want them to land on a block and stand still while I swat them with the fly swatter. But they don't seem to co-operate. Bugs in software are like that. I agree with you that the person who is doing this triage has to have some domain knowledge, and provide a first filter, but I think the filter can be much coarser than you do. That is, I put more onus on the developers than you do. Upstream is free to ignore these tickets like they are being ignored in redhat bugzilla. But if there are a thousand tickets from redhat, ubuntu, debian, suse, arch, debian with the same complaint, I think it would be evidence that there is something wrong with the upstream software (just my opinion), and the developers might want to focus some attention on the problem. i.e. where there's smoke, there's probably fire. This was only a suggestion, in the spirit of mind mapping, or brainstorming, where wild and outrageous ideas of solutions are thrown out to trigger thinking outside the box. And, if nothing else, I learned more about the problem because of your feedback. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
