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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 602BD158089 for ; Tue, 12 Sep 2023 15:04:50 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D14182BC01D; Tue, 12 Sep 2023 15:04:46 +0000 (UTC) Received: from james.steelbluetech.co.uk (james.steelbluetech.co.uk [92.63.139.228]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6B3C72BC013 for ; Tue, 12 Sep 2023 15:04:46 +0000 (UTC) Received: from ukinbox.ecrypt.net (hq2.ehuk.net [10.0.10.2]) by james.steelbluetech.co.uk (Postfix) with ESMTP id 557D7BFC11 for ; Tue, 12 Sep 2023 16:04:45 +0100 (BST) DKIM-Filter: OpenDKIM Filter v2.10.3 james.steelbluetech.co.uk 557D7BFC11 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ehuk.net; s=default; t=1694531085; bh=KDyL6jr7148ZzqHwgJBRF662ZXJqdletjxhbhqQK3MM=; h=In-Reply-To:References:Date:Subject:From:To:Reply-To:From; b=TNACAyOu2LmG9i8AbOWWVsGWLAcvrC3J+j/LiAv6FlzsE4G59RaKmf/88/EBDOb3K L4gZE7QUr5d8f5pl4/myvqzPqPi5ljgs7BVn3qqWsMuBPHtPIRMRUHilmNORGVfvy3 CYlV5BJ5OtdaSJwffEtIxm6qYM/+79mNTVnwpFdjjFjECgpZpKZxQT5CZD5IP8yvlr c2Tm3TjUYwwjkhRRe8LKRvneZU6xsxJiFJFwJwXs/qbkDWjhrmDD4e1WibT5rRQu1i jeGHfvv6bD4WR0sSTPf6Hf2ijG8kTwzcd7uq45s3QSjnnZFKAoOBdD45GqLtS4pcIh L8YbITt5VhNzA== Message-ID: <96051ecf5f26b24bd199147535b2e6b8.squirrel@ukinbox.ecrypt.net> In-Reply-To: <87ledbwk5g.fsf@gentoo.org> References: <7802203.lOV4Wx5bFT@kona> <20230911082243.65aa85f5@Akita> <4128737.ElGaqSPkdT@kona> <20230911084231.73dd619f@Akita> <5848191c-8708-edfe-0c69-eeced3907b0d@gmail.com> <87zg1szc23.fsf@gentoo.org> <5d96d41de2f7057b42b436783678c8c4.squirrel@ukinbox.ecrypt.net> <87zg1sxu88.fsf@gentoo.org> <6aca04641c105c3fc72910fdbb7b6c01.squirrel@ukinbox.ecrypt.net> <877cowxs1c.fsf@gentoo.org> <87ledbwk5g.fsf@gentoo.org> Date: Tue, 12 Sep 2023 16:04:45 +0100 Subject: Re: [gentoo-dev] last rites: sys-fs/eudev From: "Eddie Chapman" To: gentoo-dev@lists.gentoo.org User-Agent: SquirrelMail/1.5.2 [SVN] Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang X-Archives-Salt: c58373cf-cff2-47f9-a142-da5d25e8d1bb X-Archives-Hash: ca85c3472f4bfea6878675d8d44ae6b9 Sam James wrote: > > Rich Freeman writes: > >> On Tue, Sep 12, 2023 at 9:36 AM Eddie Chapman wrote: >> >>> in Gentoo. Have any of these 4 maintainers publicly said (anywhere) >>> that they are not interested in being maintainers anymore (which is >>> fine if that is the case)? We're not talking here about a lone >>> maintainer of some peripheral package that's disappeared leaving an >>> orphaned package. >> >> It isn't like somebody is censoring the lists or waging commit wars on >> the metadata.xml/mask file. If somebody was eager to maintain it I'm >> sure they'd have spoken up. >> >>> I'm an outsider to Gentoo development (just a heavy user for over a >>> decade both personally and professionally) so I might have missed >>> something. I just find it puzzling. >> >> I'm not puzzled by what is going on, or by your email, because it >> happens basically anytime a high-profile package is treecleaned. Yes, >> Gentoo is about choice, but somebody has to actually do work to make >> the choices viable. There are always more people interested in using >> software than maintaining it. The frustration is completely >> understandable, but also kinda unavoidable. >> >> Repo QA standards don't mean that it has to barely work for your >> specific use case. The package has to deal with compatibility issues >> with stuff you don't use as well, which is why maintaining a system >> package can be hard work. It is usually less of an issue for more >> ordinary applications, which tend to have fewer interactions. If it is >> "good enough" for you as it is, then just move it to a private >> overlay and keep using it. You probably would need to override a virtual >> or two as well. Or publish your work somewhere others can use it. > > Yes. We value having a coherent system with decent UX and we have > to choose what we can support. Users are free to override those choices in > local repositories - and if they want advice on the best way to do so, > they're free to ask. Yes I regularly do this if there is a piece of software not in the tree, I have a local repo full of stuff. But this argument doesn't hold as much weight when it comes to a package like this which is integrated in the core of the system. People who really want to continue using it are going to experience a lot of pain trying to maintain it for themselves out of tree, much more so than they would normally. That's one reason why I think the decision deserves more scrutiny.