From: Patrick Lauer <patrick@gentoo.org>
To: "Andreas K. Hüttel" <dilfridge@gentoo.org>,
gentoo-project@lists.gentoo.org
Subject: Re: [gentoo-project] Corporate affiliations of Council members
Date: Wed, 24 Jun 2020 21:30:08 +0200 [thread overview]
Message-ID: <ce19dbf1-ff4b-30ba-d6ac-1ca8b447bd6c@gentoo.org> (raw)
In-Reply-To: <6271494.IoEIV5pvuq@farino>
On 2020-06-23 22:50, Andreas K. Hüttel wrote:
> Am Dienstag, 23. Juni 2020, 20:48:04 EEST schrieb Patrick Lauer:
>
>> (And this is why I'm against things like the current py2 purge: There is
>> code out there that works, can't be rewritten to py3 in a reasonable
>> time*, and hasn't been rewritten in another language yet. There is no
>
>> tl;dr: I want to be lazy, so stop breaking stuff ;)
>
> You gotta be kidding me.
>
> If your employer wants to work on obsolete (yes) stuff, he should task you
> with maintaining it.
>
> In the context of a distribution that does *not* only mean "keep things until
> they are so rotten you can't distinguish them from the floor anymore", but it
> also means fixing bugs and keeping the dependency tree in a sane state.
>
> So, in this case I would strongly recommend to the higher-ups of A***** to pay
> you (or anyone else) to commit to keeping
> * not just what *you* need in Python2 maintained and working, but
> * to maintain the whole python-related package tree in a consistent state
> then.
> Not just complaining that others don't volunteer the work.
>
> (This argument applies equally to other cases, like S***.)
>
So, uhm.
I'll let you claim it was late and the beer was talking.
But that's a totally incoherent hallucination you're projecting on me.
The problem with 'obsolete' stuff is that it's often very useful, but no
one wants to spend time rewriting it.
So for example, codeswarm. The log parser it uses to convert
cvs/svn/git... logs into an intermediate representation is most horrible
python. I've patched it just enough to satisfy my needs, so I can make
nice codeswarm videos, but upstream went dormant around 2012. no chance
of having that rewritten into py3.
Young startups like Google struggle to find the manpower to migrate, see
for example Chromium still requiring python2 because ... err... yes.
Most of the stuff from the Apache Foundation is similarly unmaintained,
but the useful parts are useful so people will use them. Rewriting lots
of enterprisey code is no fun, so it won't happen soon.
If I'm not mistaken 'offlineimap' is similarly bitrotting away.
At work I have one (1) legacy bit that's used in monitoring that uses
python2, and it'll age out at some point and doesn't /need/ rewriting
because, well, why rewrite what goes into the trash can.
(Meanwhile I don't remember any code changes since perl 5.18 or so, that
stuff Just Works, even Go is easy to update with literally 4 lines of
code changing from 1.11 to 1.12 - so low-maintenance things exist, they
are just old and boring and no one talks about them)
Your hallucination that we don't update things is fascinating, but not
based on any observations.
But there's one difficulty in upgrading: Some migrations are
destructively expensive, and can't be automated easily. It took us crazy
long to migrate everything to gcc5 because upstream was unwilling to
understand dynamic linking. Incidents like that make one more
conservative ... and it would be nice if gentoo could be at least
neutral and not act as a damage amplifier for such situations.
Similarly, EOL'ing python 3.5 in Gentoo ahead of upstream caused a
little bit of friction and forced some people to spend time they had
budgeted about 2-3 months later roughly now. Which doesn't increase
their motivation, but who needs friends when you have a nice up to date
Gentoo.
Would be nice if we could minimize churn, and have reasonable upgrade
paths. Then maybe our users would spend less time on upgrades and more
on contributions (or do we want to make things artificially difficult so
we can pretend to be elite?)
Have fun,
Patrick
next prev parent reply other threads:[~2020-06-24 19:30 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-22 16:18 [gentoo-project] Corporate affiliations of Council members Michał Górny
2020-06-22 17:07 ` Brian Dolbec
2020-06-22 17:36 ` Robin H. Johnson
2020-06-22 18:20 ` Rich Freeman
2020-06-22 18:15 ` Matt Turner
2020-06-22 18:56 ` Alec Warner
2020-06-22 20:17 ` Michał Górny
2020-06-23 21:17 ` Andreas K. Hüttel
2020-06-24 5:53 ` Michał Górny
2020-06-24 11:23 ` Rich Freeman
2020-06-22 19:36 ` Ulrich Mueller
2020-06-22 20:32 ` William Hubbs
2020-06-23 13:33 ` Thomas Deutschmann
2020-06-23 17:48 ` Patrick Lauer
2020-06-23 20:50 ` Andreas K. Hüttel
2020-06-24 19:30 ` Patrick Lauer [this message]
2020-06-24 20:00 ` David Seifert
2020-06-24 20:08 ` Andreas K. Hüttel
2020-06-24 20:22 ` Patrick Lauer
2020-06-26 13:39 ` Andreas K. Huettel
2020-06-23 21:02 ` Andreas K. Hüttel
2020-06-26 1:41 ` Max Magorsch
2020-06-26 3:23 ` Aaron Bauman
2020-06-27 13:51 ` Mikle Kolyada
2020-06-28 19:57 ` Georgy Yakovlev
-- strict thread matches above, loose matches on Subject: below --
2020-07-02 17:14 Richard Yao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ce19dbf1-ff4b-30ba-d6ac-1ca8b447bd6c@gentoo.org \
--to=patrick@gentoo.org \
--cc=dilfridge@gentoo.org \
--cc=gentoo-project@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox