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 EDD851382C5 for ; Wed, 24 Jun 2020 20:00:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C9870E099B; Wed, 24 Jun 2020 20:00:42 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 8A9F0E0999 for ; Wed, 24 Jun 2020 20:00:42 +0000 (UTC) Message-ID: <26ccbee98bc6441ce494ae9dde4e30754cf50b08.camel@gentoo.org> Subject: Re: [gentoo-project] Corporate affiliations of Council members From: David Seifert To: gentoo-project@lists.gentoo.org, "Andreas K." =?ISO-8859-1?Q?H=FCttel?= Date: Wed, 24 Jun 2020 22:00:20 +0200 In-Reply-To: References: <38ba2c99-d811-8cd7-de2b-ca607f393ba8@gentoo.org> <6271494.IoEIV5pvuq@farino> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.3 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 Content-Transfer-Encoding: 8bit X-Archives-Salt: a15843b1-b61e-4093-bd18-5cdfbf2404ea X-Archives-Hash: ae0334d15dec417bfd12884c200f3557 On Wed, 2020-06-24 at 21:30 +0200, Patrick Lauer wrote: > 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 > Nothing here involves you doing anything to that end. Have you worked on making py3.7-stable a thing? No ofc not, you just demand "minimizing churn", without actually doing anything. Are you going to maintain the web of old-versions-supporting-py2 and newer-versions-supporting-only- py3? Again, of course not, you just demand others do the work for you. Case in point: Not a single commit of yours that references a bug number is GLEP 66 compliant, you continue adding ebuilds without doing a single GLEP 81 port. It's obvious that ::gentoo is just an extended overlay for you, because all the best practices clearly don't apply to you.