1 |
On 30 August 2015 at 19:20, Daniel Campbell <zlg@g.o> wrote: |
2 |
> Quick question: what is RT? |
3 |
> |
4 |
|
5 |
RT is rt.cpan.org, for which every cpan distribution that gets |
6 |
published gets a free bug tracker there |
7 |
where permissions assigned to that bug tracker reflect permissions |
8 |
granted under the CPAN authority scheme. |
9 |
|
10 |
- Every new distribution gets an RT queue whether you want it or not |
11 |
- If you don't stipulate "bug tracker" metadata in your distribution, |
12 |
then all the CPAN user interfaces will guide users to said RT queues |
13 |
- RT queues are sometimes also assumed to be "The place" to send bugs, |
14 |
even in spite of published metadata |
15 |
- RT queues can't be turned off or disabled |
16 |
- RT queues also don't require a sign up to use, and you can file bugs |
17 |
simply by sending an email to the right email address |
18 |
- And all new bugs/new feedback to RT queues sends email to the |
19 |
associated CPAN authors email address. |
20 |
|
21 |
> Regarding that, I've noticed that multiple upstreams (apparently urxvt |
22 |
> being one) have an issue with Gentoo and how 'problematic' we are as a |
23 |
> distribution because we offer so much choice to users. I'm not sure I |
24 |
> understand that attitude since makes upstreams look like they don't |
25 |
> care about the configurability of their own software. |
26 |
|
27 |
Sometimes its a social problem, not a technical one. Sometimes its |
28 |
both. Sometimes its a problem of effort. Other times its a problem |
29 |
where upstream literally can't fix our problems because they can't |
30 |
replicate them, and they can't replicate them because its something |
31 |
we're doing that causes it, and so they define that invisible |
32 |
intangible thing as a deviation from standard, and that it must be |
33 |
broken. |
34 |
|
35 |
Obviously if somebody encounters many problems of that nature, |
36 |
learning that a distribution seems "broken by default" and they don't |
37 |
want to operate with it unless the problem can be clear and |
38 |
demonstrated and well defined in an isolated context. |
39 |
|
40 |
> If Perl packages and CPAN have similar issues, how do you guys handle |
41 |
> it in perl-space? I think if I was dealing with a difficult upstream, |
42 |
> I'd try to figure out what I could do to help their build scripts |
43 |
> improve. If they were unresponsive to criticism or offers for |
44 |
> improvement, I would reroute bugs their way. |
45 |
|
46 |
Its very hard because CPAN is very anarchic, every distribution is its |
47 |
own source of irrefutable authority like a little government, where |
48 |
change in authority is something that can only happen either |
49 |
willingly, or by evidence that the author of a distribution has been |
50 |
long absent entirely. Simple stubbornness and refusal to co-operate |
51 |
are not enough, and if an author is present but negligent, we |
52 |
literally have to wash our hands of the problem and route around the |
53 |
damage. |
54 |
|
55 |
So "how we deal with a continued problem" is essentially: |
56 |
|
57 |
- Fork the problem |
58 |
- Fix the fork |
59 |
- Encourage people to use the fork. |
60 |
|
61 |
Which is essentially a direct-representation-democratization of |
62 |
changing the defaults. |
63 |
|
64 |
> |
65 |
> Historically, what is our approach to stubborn upstreams that think |
66 |
> Gentoo is the problem instead of their build scripts or packaging |
67 |
> preferences? Do we have a policy regarding difficult upstreams? |
68 |
|
69 |
Maybe here we can take the example of udev/systemd. Upstream headed in |
70 |
a direction that was at odds with the gentoo way, and their |
71 |
stubbornness dictated that "this is how its going to be", and we were |
72 |
expected to just follow suit. |
73 |
|
74 |
There's no way we can simply go "I can't use my computer any more |
75 |
because I don't want systemd" and respond with simply "tell upstream, |
76 |
not our problem". |
77 |
|
78 |
We've had to accept that upstream were being unreasonable, and fork |
79 |
the problem and manage it ourselves. |
80 |
|
81 |
And now we have eudev. |
82 |
|
83 |
This is a very good example of "Gentoo standing in between upstream |
84 |
and our users to protect our users from upstream". |
85 |
|
86 |
That's our job. To keep upstream accountable, and shield users from |
87 |
their mistakes. |
88 |
|
89 |
That's why we have all these security systems(GLSAs and related |
90 |
downstream security patching) and QA checks on upstream packages. |
91 |
|
92 |
This is also why we have install/build happen in sandbox, because we |
93 |
assume the default of "Upstream can't be trusted to be sane". |
94 |
|
95 |
-- |
96 |
Kent |
97 |
|
98 |
KENTNL - https://metacpan.org/author/KENTNL |