Re: [gentoo-dev] Better way to direct upstream bugs upstream?

[Daniel Campbell <zlg@gentoo.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/30/2015 12:03 AM, Kent Fredric wrote:
> On 30 August 2015 at 07:53, Matt Turner <mattst88@gentoo.org>
> wrote:
>> 
>> Is there a better way of directing reporters to file bugs
>> upstream? Of course it's not always clear whether a bug is an
>> ebuild bug or something easily patched in Gentoo vs a driver bug
>> that requires an upstream developer...
> 
> 
> I've always seen it as a case where Gentoo devs stand as a layer
> of sanitization between downstream and upstream.
> 
> Wherein reporting things upstream is good, but having a downstream 
> tracker for it is also good, so that when the bug is resolved 
> upstream, that the consequences of it are known to be propagated
> downstream.
> 
> And if upstream refuses to fix a bug, Gentoo devs have to choose
> how to handle that problem for downstream, sometimes patching
> around it, or if that is not simple, or not possible, to provide
> blockers where necessary, or produce end-user-visible warnings
> about problematic behaviour, etc.
> 
> So, even in the case users are prompted to file bugs upstream
> first, they should also at minimum report to gentoo when the bug is
> resolved upstream so that the fix can be replicated.
> 
> Its also not always abundantly clear to end users where upstream
> is, and there are potholes in that process. For instance, in Perl
> space, the "Current upstream reporting que" is often RT, but it can
> be github, and knowing exactly where the reporting queue
> *currently* is something that can't be reliably replicated in
> metadata.xml, because it can change on a whim, and sometimes the
> metadata visible on the CPAN sources is also wrong, and requires an
> experienced developer to chase its tail to work out where it
> currently is.
> 
> And there are some upstreams on CPAN where there is no documented
> or stated bug reporting mechanism, and in such cases, the metadata
> will encourage you to use the defacto standard, RT, and doing so
> for some upstreams will get you automated mails that will possibly
> make the reporter recoil in a corner for a bit.
> 
> I know and have had moderate success in dealing with upstreams
> like that, because I've worked out from listening to people talk
> how/where to actaully talk about problems and try to work out how
> to say things in a way that will work.
> 
> ( That is, I'm a much better reporter at reporting faults found in 
> gentoo to some upstreams than any user could hope to be )
> 
> There are also cases where users reporting direct to upstream just 
> irritates upstream, because its a breakage/potential breakage due
> to something gentoo does, and you have the whole hostile "not our 
> problem, you're on gentoo, you get to keep the pieces" response.
> 
> For these reasons, I think its best that those with the most
> knowledge of how upstream works, ( us, the developers ) handle
> reports from end users and ferry them upstream.
> 

Quick question: what is RT?

Regarding that, I've noticed that multiple upstreams (apparently urxvt
being one) have an issue with Gentoo and how 'problematic' we are as a
distribution because we offer so much choice to users. I'm not sure I
understand that attitude since makes upstreams look like they don't
care about the configurability of their own software.

If Perl packages and CPAN have similar issues, how do you guys handle
it in perl-space? I think if I was dealing with a difficult upstream,
I'd try to figure out what I could do to help their build scripts
improve. If they were unresponsive to criticism or offers for
improvement, I would reroute bugs their way.

Historically, what is our approach to stubborn upstreams that think
Gentoo is the problem instead of their build scripts or packaging
preferences? Do we have a policy regarding difficult upstreams?

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJV4q6kAAoJEAEkDpRQOeFwin4QAMKIC2WwOlfdsZ1U9WKnmgP1
Aussqt36Fcw4HR50lJ4rqxmkax2QIbF7msDjR/keoW9ZQ/IjcCObXy5XATthw2lJ
g2nNS3TLKRtpQxA4baZsZqlLUpPOTNOKm7KArA9e1PCfELdViVD9aSlYWGfmz0Ns
efcXJUjN22uHgx2Awqpj9+jg1o/wgonnryYwMAHxvzfFeIdVd9zV4Af8IyXz7Qh9
tp1/UfMLYE/40sne7NVd/2sZpJHFD0WW8ViPEYkJFtYySwR3KRwNfu/S/7iLhiKB
pG5Mqneq0taN4EWXYX7wSG6w5dr5EWMiN5ftPI/mXDSfElTZY7H6U4KjXMi5eNU2
Wm8HjfrGtTm8pOJhd1EZ9otBSCWVGySTEeTGFEUEQokMor62Ff9/jVCB20hw6Hrf
oP79U+VyZlLcejW9kCEP+dUdnjLgO81uxLbcp3r35A05lwgUPnLltT+9/nFwY6ut
VgEWxUNHrIsr6eUTZQ53OeB/VDxf3yyJcIg1ysdN9jGVHM/W5/DuDCe+/sttOMD1
7C/wGLVfltZEVets2EAr+ks76sTG8/Miurr79J/f07Z8TU1qKhjyCri2+7cuIuOZ
B51HQ1NdI9TNEa68/c7MKtKwYLfwQTcEndQgRnRL8ZDLGPMZIJuKDKUb5OHsWilC
Xc53D+mRG+YGy+rcL73E
=QWFf
-----END PGP SIGNATURE-----