From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id AC8BB1382C5 for ; Wed, 24 Jun 2020 19:30:40 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 87397E0984; Wed, 24 Jun 2020 19:30:39 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 5D25FE097D for ; Wed, 24 Jun 2020 19:30:39 +0000 (UTC) Subject: Re: [gentoo-project] Corporate affiliations of Council members To: =?UTF-8?Q?Andreas_K=2e_H=c3=bcttel?= , gentoo-project@lists.gentoo.org References: <38ba2c99-d811-8cd7-de2b-ca607f393ba8@gentoo.org> <6271494.IoEIV5pvuq@farino> From: Patrick Lauer Message-ID: Date: Wed, 24 Jun 2020 21:30:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 In-Reply-To: <6271494.IoEIV5pvuq@farino> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Archives-Salt: 4bd762f6-b249-4a85-973b-1999aef1b52d X-Archives-Hash: 15060e3ab780822a1337c2d9ee68c77a 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