Gentoo Archives: gentoo-dev

From: Daniel Campbell <zlg@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Better way to direct upstream bugs upstream?
Date: Sun, 30 Aug 2015 07:59:22
Message-Id: 55E2B7D6.5060508@gentoo.org
In Reply to: Re: [gentoo-dev] Better way to direct upstream bugs upstream? by Kent Fredric
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-----