Gentoo Archives: gentoo-project

From: David Seifert <soap@g.o>
To: gentoo-project@l.g.o, "Andreas K." <dilfridge@g.o>
Subject: Re: [gentoo-project] Corporate affiliations of Council members
Date: Wed, 24 Jun 2020 20:00:43
Message-Id: 26ccbee98bc6441ce494ae9dde4e30754cf50b08.camel@gentoo.org
In Reply to: Re: [gentoo-project] Corporate affiliations of Council members by Patrick Lauer
1 On Wed, 2020-06-24 at 21:30 +0200, Patrick Lauer wrote:
2 > On 2020-06-23 22:50, Andreas K. Hüttel wrote:
3 > > Am Dienstag, 23. Juni 2020, 20:48:04 EEST schrieb Patrick Lauer:
4 > >
5 > > > (And this is why I'm against things like the current py2 purge:
6 > > > There is
7 > > > code out there that works, can't be rewritten to py3 in a
8 > > > reasonable
9 > > > time*, and hasn't been rewritten in another language yet. There is
10 > > > no
11 > > > tl;dr: I want to be lazy, so stop breaking stuff ;)
12 > >
13 > > You gotta be kidding me.
14 > >
15 > > If your employer wants to work on obsolete (yes) stuff, he should
16 > > task you
17 > > with maintaining it.
18 > >
19 > > In the context of a distribution that does *not* only mean "keep
20 > > things until
21 > > they are so rotten you can't distinguish them from the floor
22 > > anymore", but it
23 > > also means fixing bugs and keeping the dependency tree in a sane
24 > > state.
25 > >
26 > > So, in this case I would strongly recommend to the higher-ups of
27 > > A***** to pay
28 > > you (or anyone else) to commit to keeping
29 > > * not just what *you* need in Python2 maintained and working, but
30 > > * to maintain the whole python-related package tree in a consistent
31 > > state
32 > > then.
33 > > Not just complaining that others don't volunteer the work.
34 > >
35 > > (This argument applies equally to other cases, like S***.)
36 > >
37 >
38 > So, uhm.
39 > I'll let you claim it was late and the beer was talking.
40 >
41 > But that's a totally incoherent hallucination you're projecting on me.
42 >
43 >
44 > The problem with 'obsolete' stuff is that it's often very useful, but
45 > no
46 > one wants to spend time rewriting it.
47 >
48 > So for example, codeswarm. The log parser it uses to convert
49 > cvs/svn/git... logs into an intermediate representation is most
50 > horrible
51 > python. I've patched it just enough to satisfy my needs, so I can
52 > make
53 > nice codeswarm videos, but upstream went dormant around 2012. no
54 > chance
55 > of having that rewritten into py3.
56 >
57 > Young startups like Google struggle to find the manpower to migrate,
58 > see
59 > for example Chromium still requiring python2 because ... err... yes.
60 >
61 > Most of the stuff from the Apache Foundation is similarly
62 > unmaintained,
63 > but the useful parts are useful so people will use them. Rewriting
64 > lots
65 > of enterprisey code is no fun, so it won't happen soon.
66 >
67 > If I'm not mistaken 'offlineimap' is similarly bitrotting away.
68 >
69 >
70 > At work I have one (1) legacy bit that's used in monitoring that uses
71 > python2, and it'll age out at some point and doesn't /need/ rewriting
72 > because, well, why rewrite what goes into the trash can.
73 > (Meanwhile I don't remember any code changes since perl 5.18 or so,
74 > that
75 > stuff Just Works, even Go is easy to update with literally 4 lines of
76 > code changing from 1.11 to 1.12 - so low-maintenance things exist,
77 > they
78 > are just old and boring and no one talks about them)
79 >
80 > Your hallucination that we don't update things is fascinating, but
81 > not
82 > based on any observations.
83 >
84 > But there's one difficulty in upgrading: Some migrations are
85 > destructively expensive, and can't be automated easily. It took us
86 > crazy
87 > long to migrate everything to gcc5 because upstream was unwilling to
88 > understand dynamic linking. Incidents like that make one more
89 > conservative ... and it would be nice if gentoo could be at least
90 > neutral and not act as a damage amplifier for such situations.
91 >
92 > Similarly, EOL'ing python 3.5 in Gentoo ahead of upstream caused a
93 > little bit of friction and forced some people to spend time they had
94 > budgeted about 2-3 months later roughly now. Which doesn't increase
95 > their motivation, but who needs friends when you have a nice up to
96 > date
97 > Gentoo.
98 >
99 > Would be nice if we could minimize churn, and have reasonable upgrade
100 > paths. Then maybe our users would spend less time on upgrades and
101 > more
102 > on contributions (or do we want to make things artificially difficult
103 > so
104 > we can pretend to be elite?)
105 >
106 >
107 > Have fun,
108 >
109 > Patrick
110 >
111
112 Nothing here involves you doing anything to that end. Have you worked on
113 making py3.7-stable a thing? No ofc not, you just demand "minimizing
114 churn", without actually doing anything. Are you going to maintain the
115 web of old-versions-supporting-py2 and newer-versions-supporting-only-
116 py3? Again, of course not, you just demand others do the work for you.
117 Case in point: Not a single commit of yours that references a bug number
118 is GLEP 66 compliant, you continue adding ebuilds without doing a single
119 GLEP 81 port. It's obvious that ::gentoo is just an extended overlay for
120 you, because all the best practices clearly don't apply to you.