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. |