1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA256 |
3 |
|
4 |
On 08/30/2015 12:54 AM, Kent Fredric wrote: |
5 |
> On 30 August 2015 at 19:20, Daniel Campbell <zlg@g.o> |
6 |
> wrote: |
7 |
>> Quick question: what is RT? |
8 |
>> |
9 |
> |
10 |
> RT is rt.cpan.org, for which every cpan distribution that gets |
11 |
> published gets a free bug tracker there where permissions assigned |
12 |
> to that bug tracker reflect permissions granted under the CPAN |
13 |
> authority scheme. |
14 |
> |
15 |
> - Every new distribution gets an RT queue whether you want it or |
16 |
> not - If you don't stipulate "bug tracker" metadata in your |
17 |
> distribution, then all the CPAN user interfaces will guide users to |
18 |
> said RT queues - RT queues are sometimes also assumed to be "The |
19 |
> place" to send bugs, even in spite of published metadata - RT |
20 |
> queues can't be turned off or disabled - RT queues also don't |
21 |
> require a sign up to use, and you can file bugs simply by sending |
22 |
> an email to the right email address - And all new bugs/new feedback |
23 |
> to RT queues sends email to the associated CPAN authors email |
24 |
> address. |
25 |
> |
26 |
>> Regarding that, I've noticed that multiple upstreams (apparently |
27 |
>> urxvt being one) have an issue with Gentoo and how 'problematic' |
28 |
>> we are as a distribution because we offer so much choice to |
29 |
>> users. I'm not sure I understand that attitude since makes |
30 |
>> upstreams look like they don't care about the configurability of |
31 |
>> their own software. |
32 |
> |
33 |
> Sometimes its a social problem, not a technical one. Sometimes its |
34 |
> both. Sometimes its a problem of effort. Other times its a problem |
35 |
> where upstream literally can't fix our problems because they can't |
36 |
> replicate them, and they can't replicate them because its |
37 |
> something we're doing that causes it, and so they define that |
38 |
> invisible intangible thing as a deviation from standard, and that |
39 |
> it must be broken. |
40 |
> |
41 |
> Obviously if somebody encounters many problems of that nature, |
42 |
> learning that a distribution seems "broken by default" and they |
43 |
> don't want to operate with it unless the problem can be clear and |
44 |
> demonstrated and well defined in an isolated context. |
45 |
> |
46 |
>> If Perl packages and CPAN have similar issues, how do you guys |
47 |
>> handle it in perl-space? I think if I was dealing with a |
48 |
>> difficult upstream, I'd try to figure out what I could do to help |
49 |
>> their build scripts improve. If they were unresponsive to |
50 |
>> criticism or offers for improvement, I would reroute bugs their |
51 |
>> way. |
52 |
> |
53 |
> Its very hard because CPAN is very anarchic, every distribution is |
54 |
> its own source of irrefutable authority like a little government, |
55 |
> where change in authority is something that can only happen either |
56 |
> willingly, or by evidence that the author of a distribution has |
57 |
> been long absent entirely. Simple stubbornness and refusal to |
58 |
> co-operate are not enough, and if an author is present but |
59 |
> negligent, we literally have to wash our hands of the problem and |
60 |
> route around the damage. |
61 |
> |
62 |
> So "how we deal with a continued problem" is essentially: |
63 |
> |
64 |
> - Fork the problem - Fix the fork - Encourage people to use the |
65 |
> fork. |
66 |
> |
67 |
> Which is essentially a direct-representation-democratization of |
68 |
> changing the defaults. |
69 |
> |
70 |
>> |
71 |
>> Historically, what is our approach to stubborn upstreams that |
72 |
>> think Gentoo is the problem instead of their build scripts or |
73 |
>> packaging preferences? Do we have a policy regarding difficult |
74 |
>> upstreams? |
75 |
> |
76 |
> Maybe here we can take the example of udev/systemd. Upstream headed |
77 |
> in a direction that was at odds with the gentoo way, and their |
78 |
> stubbornness dictated that "this is how its going to be", and we |
79 |
> were expected to just follow suit. |
80 |
> |
81 |
> There's no way we can simply go "I can't use my computer any more |
82 |
> because I don't want systemd" and respond with simply "tell |
83 |
> upstream, not our problem". |
84 |
> |
85 |
> We've had to accept that upstream were being unreasonable, and |
86 |
> fork the problem and manage it ourselves. |
87 |
> |
88 |
> And now we have eudev. |
89 |
> |
90 |
> This is a very good example of "Gentoo standing in between |
91 |
> upstream and our users to protect our users from upstream". |
92 |
> |
93 |
> That's our job. To keep upstream accountable, and shield users |
94 |
> from their mistakes. |
95 |
> |
96 |
> That's why we have all these security systems(GLSAs and related |
97 |
> downstream security patching) and QA checks on upstream packages. |
98 |
> |
99 |
> This is also why we have install/build happen in sandbox, because |
100 |
> we assume the default of "Upstream can't be trusted to be sane". |
101 |
> |
102 |
Thanks for that write-up. Simple to understand and (imo anyway) really |
103 |
represents one of the reasons I became a developer. I like the idea of |
104 |
protecting our users' choices and creating a system that's sane, |
105 |
despite (or in spite :P) of our upstreams. |
106 |
|
107 |
- -- |
108 |
Daniel Campbell - Gentoo Developer |
109 |
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net |
110 |
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 |
111 |
-----BEGIN PGP SIGNATURE----- |
112 |
Version: GnuPG v2 |
113 |
|
114 |
iQIcBAEBCAAGBQJV4rfVAAoJEAEkDpRQOeFw4TsQANecNmZCKnSi19nifRxzTGak |
115 |
o74AjlPUvaKFJu3nO8bABPo1FrkSwa0lta+hSY5CB223XRjT3PXu8kAi3lgUOVQz |
116 |
jK89Fs1yIXULDV5pA2/26UDcGLtfzENfpdd5P8qNgLNb9ky+RB30IbJzzG5DxLbD |
117 |
qG/nQ7CkozRp2Nbkr1U7u1gbbf/jW0L4CXE0dI2tZIDB0VIXLspNjYrj0nXA9hAj |
118 |
9OGa6nnxIZCE9nrirnAk4rFxT0NwJWbeCEiqbeRR6A+YyekTvVlzQGZSvxHs6hBu |
119 |
jXhoZOwGqIu2jV/ezjEZ8OlEnAbGzMscQjr7PxSMchJG4O8uo8R/E0+HRveSjFwd |
120 |
BR/mgAgmD+YRw8FetWN5fTiecuXbLSZvvQRAyLjrR4ZQJTtrtWJcBTZfWhHQAItX |
121 |
N+Rq0EHpD4RXGE3h5GqP6sZ0TLOgA5/2CBGTkng2F6pc+8mC0gWXse9asJjdm72V |
122 |
XF9LYpLxaixzEhioDSwMok43Nj6F/3GA4LuuqKsQSqS9pSe5KuLA135NtfKAu4Cy |
123 |
8OWcYLsB7OHycDhZZLJwkQA3JaV+LjHD219BZcsssJBkGXZKx9OuftFst6/9JB93 |
124 |
wdBIt4PqIOA8mrGRbvZTC3qkQ3d3JdRHYq3ceSig+hwKga04g1ny6qBuWrFdspZp |
125 |
UVeuwYM1F7bkxBUSkuAD |
126 |
=PF3g |
127 |
-----END PGP SIGNATURE----- |