1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA256 |
3 |
|
4 |
On 08/30/2015 12:03 AM, Kent Fredric wrote: |
5 |
> On 30 August 2015 at 07:53, Matt Turner <mattst88@g.o> |
6 |
> wrote: |
7 |
>> |
8 |
>> Is there a better way of directing reporters to file bugs |
9 |
>> upstream? Of course it's not always clear whether a bug is an |
10 |
>> ebuild bug or something easily patched in Gentoo vs a driver bug |
11 |
>> that requires an upstream developer... |
12 |
> |
13 |
> |
14 |
> I've always seen it as a case where Gentoo devs stand as a layer |
15 |
> of sanitization between downstream and upstream. |
16 |
> |
17 |
> Wherein reporting things upstream is good, but having a downstream |
18 |
> tracker for it is also good, so that when the bug is resolved |
19 |
> upstream, that the consequences of it are known to be propagated |
20 |
> downstream. |
21 |
> |
22 |
> And if upstream refuses to fix a bug, Gentoo devs have to choose |
23 |
> how to handle that problem for downstream, sometimes patching |
24 |
> around it, or if that is not simple, or not possible, to provide |
25 |
> blockers where necessary, or produce end-user-visible warnings |
26 |
> about problematic behaviour, etc. |
27 |
> |
28 |
> So, even in the case users are prompted to file bugs upstream |
29 |
> first, they should also at minimum report to gentoo when the bug is |
30 |
> resolved upstream so that the fix can be replicated. |
31 |
> |
32 |
> Its also not always abundantly clear to end users where upstream |
33 |
> is, and there are potholes in that process. For instance, in Perl |
34 |
> space, the "Current upstream reporting que" is often RT, but it can |
35 |
> be github, and knowing exactly where the reporting queue |
36 |
> *currently* is something that can't be reliably replicated in |
37 |
> metadata.xml, because it can change on a whim, and sometimes the |
38 |
> metadata visible on the CPAN sources is also wrong, and requires an |
39 |
> experienced developer to chase its tail to work out where it |
40 |
> currently is. |
41 |
> |
42 |
> And there are some upstreams on CPAN where there is no documented |
43 |
> or stated bug reporting mechanism, and in such cases, the metadata |
44 |
> will encourage you to use the defacto standard, RT, and doing so |
45 |
> for some upstreams will get you automated mails that will possibly |
46 |
> make the reporter recoil in a corner for a bit. |
47 |
> |
48 |
> I know and have had moderate success in dealing with upstreams |
49 |
> like that, because I've worked out from listening to people talk |
50 |
> how/where to actaully talk about problems and try to work out how |
51 |
> to say things in a way that will work. |
52 |
> |
53 |
> ( That is, I'm a much better reporter at reporting faults found in |
54 |
> gentoo to some upstreams than any user could hope to be ) |
55 |
> |
56 |
> There are also cases where users reporting direct to upstream just |
57 |
> irritates upstream, because its a breakage/potential breakage due |
58 |
> to something gentoo does, and you have the whole hostile "not our |
59 |
> problem, you're on gentoo, you get to keep the pieces" response. |
60 |
> |
61 |
> For these reasons, I think its best that those with the most |
62 |
> knowledge of how upstream works, ( us, the developers ) handle |
63 |
> reports from end users and ferry them upstream. |
64 |
> |
65 |
|
66 |
Quick question: what is RT? |
67 |
|
68 |
Regarding that, I've noticed that multiple upstreams (apparently urxvt |
69 |
being one) have an issue with Gentoo and how 'problematic' we are as a |
70 |
distribution because we offer so much choice to users. I'm not sure I |
71 |
understand that attitude since makes upstreams look like they don't |
72 |
care about the configurability of their own software. |
73 |
|
74 |
If Perl packages and CPAN have similar issues, how do you guys handle |
75 |
it in perl-space? I think if I was dealing with a difficult upstream, |
76 |
I'd try to figure out what I could do to help their build scripts |
77 |
improve. If they were unresponsive to criticism or offers for |
78 |
improvement, I would reroute bugs their way. |
79 |
|
80 |
Historically, what is our approach to stubborn upstreams that think |
81 |
Gentoo is the problem instead of their build scripts or packaging |
82 |
preferences? Do we have a policy regarding difficult upstreams? |
83 |
|
84 |
- -- |
85 |
Daniel Campbell - Gentoo Developer |
86 |
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net |
87 |
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 |
88 |
-----BEGIN PGP SIGNATURE----- |
89 |
Version: GnuPG v2 |
90 |
|
91 |
iQIcBAEBCAAGBQJV4q6kAAoJEAEkDpRQOeFwin4QAMKIC2WwOlfdsZ1U9WKnmgP1 |
92 |
Aussqt36Fcw4HR50lJ4rqxmkax2QIbF7msDjR/keoW9ZQ/IjcCObXy5XATthw2lJ |
93 |
g2nNS3TLKRtpQxA4baZsZqlLUpPOTNOKm7KArA9e1PCfELdViVD9aSlYWGfmz0Ns |
94 |
efcXJUjN22uHgx2Awqpj9+jg1o/wgonnryYwMAHxvzfFeIdVd9zV4Af8IyXz7Qh9 |
95 |
tp1/UfMLYE/40sne7NVd/2sZpJHFD0WW8ViPEYkJFtYySwR3KRwNfu/S/7iLhiKB |
96 |
pG5Mqneq0taN4EWXYX7wSG6w5dr5EWMiN5ftPI/mXDSfElTZY7H6U4KjXMi5eNU2 |
97 |
Wm8HjfrGtTm8pOJhd1EZ9otBSCWVGySTEeTGFEUEQokMor62Ff9/jVCB20hw6Hrf |
98 |
oP79U+VyZlLcejW9kCEP+dUdnjLgO81uxLbcp3r35A05lwgUPnLltT+9/nFwY6ut |
99 |
VgEWxUNHrIsr6eUTZQ53OeB/VDxf3yyJcIg1ysdN9jGVHM/W5/DuDCe+/sttOMD1 |
100 |
7C/wGLVfltZEVets2EAr+ks76sTG8/Miurr79J/f07Z8TU1qKhjyCri2+7cuIuOZ |
101 |
B51HQ1NdI9TNEa68/c7MKtKwYLfwQTcEndQgRnRL8ZDLGPMZIJuKDKUb5OHsWilC |
102 |
Xc53D+mRG+YGy+rcL73E |
103 |
=QWFf |
104 |
-----END PGP SIGNATURE----- |