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 972AF158089 for ; Tue, 12 Sep 2023 15:35:24 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B9D482BC01D; Tue, 12 Sep 2023 15:35:19 +0000 (UTC) Received: from mx0.riseup.net (mx0.riseup.net [198.252.153.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 816F42BC013 for ; Tue, 12 Sep 2023 15:35:19 +0000 (UTC) Received: from fews01-sea.riseup.net (fews01-sea-pn.riseup.net [10.0.1.109]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx0.riseup.net (Postfix) with ESMTPS id 4RlSMV4V6Nz9t0W for ; Tue, 12 Sep 2023 15:35:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1694532918; bh=HSDn6zQ4PZytEKonskIClpSbqhiy/+yEBUkBHH6jXuA=; h=Date:From:To:Subject:In-Reply-To:References:From; b=eKJ4+im+ZSIEVR/EzUuM/5kDguj2/UsIA+N+urtQoteNx0zbpV6qpPfQu6GzBpI18 V8VxB2I8/PjXvlXLkSm3Sb6rqZC5JyRMKYje0mEIsPxJqKrIRu+w2LK4OZOsfqGB0Z QRXx0/h160TOK+h3tQ9SK9gzAAb6kXHFi0u4jDV8= X-Riseup-User-ID: 7A873EAB5FD4286526D79505EF4348ED7BA0358D14E784A37E7CACD245173E24 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews01-sea.riseup.net (Postfix) with ESMTPSA id 4RlSMV3GyrzJnsj for ; Tue, 12 Sep 2023 15:35:18 +0000 (UTC) Date: Tue, 12 Sep 2023 08:35:17 -0700 From: orbea To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] last rites: sys-fs/eudev Message-ID: <20230912083517.65561251@Akita> 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> 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: quoted-printable X-Archives-Salt: 5f41f121-3c40-4fb4-b191-8a83324a1a43 X-Archives-Hash: 3b1289b4a48a0fd826750ab8254089d6 On Tue, 12 Sep 2023 15:17:00 +0100 Sam James wrote: > Rich Freeman writes: >=20 > > On Tue, Sep 12, 2023 at 9:36=E2=80=AFAM Eddie Chapman > > wrote: =20 > >> 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. =20 > > > > 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. > > =20 > >> 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. =20 > > > > 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. =20 >=20 > 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. >=20 As evidenced by the ::libressl overlay where I am repeatedly copy/pasting changes from ::gentoo that have nothing to do with libressl this is not a very good solution. This is a huge amount of redundant and pointless effort that would be better suited being directly in the ::gentoo repo. What would be required so this is not required for eudev too? At the risk of repeating myself its working on my systems and I am willing to look at bugs and put in effort into keeping it functional. I don't think this is a matter of not having people willing to put effort in, but that no one wants to let them have the chance.