On Fri, 16 Sep 2016 17:19:24 +0000
Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> 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
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
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 -- email@example.com
To unsubscribe send an email to devel-le...@lists.fedoraproject.org