Gentoo Archives: gentoo-dev

From: Kent Fredric <kentfredric@×××××.com>
To: gentoo-dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] Better way to direct upstream bugs upstream?
Date: Sun, 30 Aug 2015 07:55:16
Message-Id: CAATnKFApsOQqVyE8ja94Bprwb1J6vfuDGCF6EJm2oT_3F-32cA@mail.gmail.com
In Reply to: Re: [gentoo-dev] Better way to direct upstream bugs upstream? by Daniel Campbell
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

Replies

Subject Author
Re: [gentoo-dev] Better way to direct upstream bugs upstream? Daniel Campbell <zlg@g.o>