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:54 AM, Kent Fredric wrote:
> On 30 August 2015 at 19:20, Daniel Campbell <zlg@gentoo.org>
> wrote:
>> Quick question: what is RT?
>> 
> 
> RT is rt.cpan.org, for which every cpan distribution that gets 
> published gets a free bug tracker there where permissions assigned
> to that bug tracker reflect permissions granted under the CPAN
> authority scheme.
> 
> - Every new distribution gets an RT queue whether you want it or
> not - If you don't stipulate "bug tracker" metadata in your
> distribution, then all the CPAN user interfaces will guide users to
> said RT queues - RT queues are sometimes also assumed to be "The
> place" to send bugs, even in spite of published metadata - RT
> queues can't be turned off or disabled - RT queues also don't
> require a sign up to use, and you can file bugs simply by sending
> an email to the right email address - And all new bugs/new feedback
> to RT queues sends email to the associated CPAN authors email
> address.
> 
>> 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.
> 
> Sometimes its a social problem, not a technical one. Sometimes its 
> both. Sometimes its a problem of effort. Other times its a problem 
> where upstream literally can't fix our problems because they can't 
> replicate them, and they can't replicate them because its
> something we're doing that causes it, and so they define that
> invisible intangible thing as a deviation from standard, and that
> it must be broken.
> 
> Obviously if somebody encounters many problems of that nature, 
> learning that a distribution seems "broken by default" and they
> don't want to operate with it unless the problem can be clear and 
> demonstrated and well defined in an isolated context.
> 
>> 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.
> 
> Its very hard because CPAN is very anarchic, every distribution is
> its own source of irrefutable authority like  a little government,
> where change in authority is something that can only happen either 
> willingly, or by evidence that the author of a distribution has
> been long absent entirely. Simple stubbornness and refusal to
> co-operate are not enough, and if an author is present but
> negligent, we literally have to wash our hands of the problem and
> route around the damage.
> 
> So "how we deal with a continued problem" is essentially:
> 
> - Fork the problem - Fix the fork - Encourage people to use the
> fork.
> 
> Which is essentially a direct-representation-democratization of 
> changing the defaults.
> 
>> 
>> 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?
> 
> Maybe here we can take the example of udev/systemd. Upstream headed
> in a direction that was at odds with the gentoo way, and their 
> stubbornness dictated that "this is how its going to be", and we
> were expected to just follow suit.
> 
> There's no way we can simply go "I can't use my computer any more 
> because I don't want systemd" and respond with simply "tell
> upstream, not our problem".
> 
> We've had to accept that upstream were being unreasonable, and
> fork the problem and manage it ourselves.
> 
> And now we have eudev.
> 
> This is a very good example of "Gentoo standing in between
> upstream and our users to protect our users from upstream".
> 
> That's our job. To keep upstream accountable, and shield users
> from their mistakes.
> 
> That's why we have all these security systems(GLSAs and related 
> downstream security patching) and QA checks on upstream packages.
> 
> This is also why we have install/build happen in sandbox, because
> we assume the default of "Upstream can't be trusted to be sane".
> 
Thanks for that write-up. Simple to understand and (imo anyway) really
represents one of the reasons I became a developer. I like the idea of
protecting our users' choices and creating a system that's sane,
despite (or in spite :P) of our 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

iQIcBAEBCAAGBQJV4rfVAAoJEAEkDpRQOeFw4TsQANecNmZCKnSi19nifRxzTGak
o74AjlPUvaKFJu3nO8bABPo1FrkSwa0lta+hSY5CB223XRjT3PXu8kAi3lgUOVQz
jK89Fs1yIXULDV5pA2/26UDcGLtfzENfpdd5P8qNgLNb9ky+RB30IbJzzG5DxLbD
qG/nQ7CkozRp2Nbkr1U7u1gbbf/jW0L4CXE0dI2tZIDB0VIXLspNjYrj0nXA9hAj
9OGa6nnxIZCE9nrirnAk4rFxT0NwJWbeCEiqbeRR6A+YyekTvVlzQGZSvxHs6hBu
jXhoZOwGqIu2jV/ezjEZ8OlEnAbGzMscQjr7PxSMchJG4O8uo8R/E0+HRveSjFwd
BR/mgAgmD+YRw8FetWN5fTiecuXbLSZvvQRAyLjrR4ZQJTtrtWJcBTZfWhHQAItX
N+Rq0EHpD4RXGE3h5GqP6sZ0TLOgA5/2CBGTkng2F6pc+8mC0gWXse9asJjdm72V
XF9LYpLxaixzEhioDSwMok43Nj6F/3GA4LuuqKsQSqS9pSe5KuLA135NtfKAu4Cy
8OWcYLsB7OHycDhZZLJwkQA3JaV+LjHD219BZcsssJBkGXZKx9OuftFst6/9JB93
wdBIt4PqIOA8mrGRbvZTC3qkQ3d3JdRHYq3ceSig+hwKga04g1ny6qBuWrFdspZp
UVeuwYM1F7bkxBUSkuAD
=PF3g
-----END PGP SIGNATURE-----