Bug#908155: Coordination with upstream developers not universally applied
On Thu, 6 Sep 2018, Moritz Muehlenhoff wrote:
> "You have to forward these bug reports to the upstream developers so that they
> can be fixed in a future upstream release."
>
> That's not the current/best practice for a number of packages, either because
> of the sheer volume of bug reports/size of the package or because some of the
> bugs are very specific to the reporters setup and having the Debian maintainer
> as a middle person forwarding information back and forth would be useless
> (e.g. for the Linux kernel where a lot of bug reports are hardware-specific).
I respectfully disagree.
In just as many cases, the middle person is necessary, because it’s
a burden to the end user (and often enough virtually impossible) to
• register an account on 10'000 upstream bugtrackers, with 30 different
kinds of bug tracking systems (if any), themselves (one for each pak‐
kage they use)
‣ finding the tracker in the first place
‣ reporting it in the correct tracker, against the correct
component, in the correct format, etc.
• keep track of the state of these bugs (we have debbugs with a sub‐
scription interface as a single consistent interface for a reason)
• respond to back-questions from upstream (which version, compile
options, why did you patch X, etc)
‣ deal with upstreams not interested in bugreports for anything stable
• tell upstream convincingly enough that no, you can’t just build
and use their git master
‣ (the real package maintainers could pick the proposed fix and
put it in experimental, though, or prepare, if necessary, a
special build for the reporter to test back)
• well, build the proposed fix for testing
• reproduce the bug with older (think oldstable-security) or newer
(think sid, for a stable user) versions
• keep track of whatever upstream versions and whatever Debian
versions carry the fix (those can differ quite a lot)
• be able to judge whether it’s a security-relevant problem
• speak upstream’s language (both programming and human) well
enough for both sides to understand stuff
• etc.
Furthermore, it’s considered nice to upstream to filter out
Debian-specific bugs instead.
One could even argue with Social Contract §4 here, but I’m
not going quite as far.
Yes, I’ve also been guilty of asking users to report things
upstream as they aren’t packaging-specific. (I’d still move
or copy them upstream if the reporter is unable or unwilling.)
However, I *still* think the language of DevRef should be
*strongly* urging DDs (and other package maintainers) towards
being a bidirectional bug report gateway, at least for real
problems (I can understand being annoyed with upstream feature
requests).
Yes, that doesn’t scale when you maintain “a lot of” packages.
However, it *is* something you have signed up for when you
started maintaining your first package. Perhaps you should
look for help (bug triage and forwarding could even be done,
in part, by less involved people).
I also think that upstreams, conversely, should have an eye
on packaging bugtrackers, but that can explode quickly… I’m
trying for mine (Debian, CentOS/RedHat, Gentoo, Arch seems
to be a manageable subset, and I pick up weird ones like Void
on the occasion).
So, perhaps upstream can help those “a lot of” maintainers, too.
This also means that there should be a good relationship
between the package maintainers and upstreams. In those,
it’s easier to deal with bugreports than when someone
totally unknown goes to upstream and reports a bug (“uh,
a clueless end user… meh, let’s ignore it”). It’s basically
the *definition* of a distribution and its maintainers to
coordinate between upstreams, other packages and distro-wide
policies, and users and other downstreams. It’s your *job*!
I’m trying to be constructive here, but in the end, I still
think that this was something package maintainers (at least
DDs) have read beforehand and signed up for, so there’s no
room to complain now, and I strongly believe that the current
wording should either not be changed at all, or changed in a
way that still strongly supports users unable (by lack of
knowledge, skills, or just time) to report directly upstream.
Thanks for having read till the end,
//mirabilos
--
15:41⎜<Lo-lan-do:#fusionforge> Somebody write a testsuite for helloworld :-)
Reply to: