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 22F40158009 for ; Fri, 30 Jun 2023 08:30:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 30A0BE08A2; Fri, 30 Jun 2023 08:30:15 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (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 D2A89E0899 for ; Fri, 30 Jun 2023 08:30:14 +0000 (UTC) References: <2ZKWN4KF.MKEFFMWE.LGPKYP47@RTL7EJXF.RN4PF6UF.MDFBGF3C> <87y1k33aoy.fsf@gentoo.org> <5b5e5a30-6fcc-7a9d-6c91-67d9a6a5c560@gentoo.org> User-agent: mu4e 1.10.4; emacs 29.0.92 From: Sam James To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.) Date: Fri, 30 Jun 2023 09:22:29 +0100 In-reply-to: <5b5e5a30-6fcc-7a9d-6c91-67d9a6a5c560@gentoo.org> Message-ID: <87jzvl2vzh.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: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Archives-Salt: bd9efe2b-611e-406d-aed1-36cf03000a31 X-Archives-Hash: 7b536a65da0a583d898cf8b246388a76 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Florian Schmaus writes: > [[PGP Signed Part:Undecided]] > [in reply to a gentoo-project@ post, but it was asked to continue this > on gentoo-dev@] > > On 28/06/2023 16.46, Sam James wrote: >> Florian Schmaus writes: >>> On 17/06/2023 10.37, Arthur Zamarin wrote: >>>> I also want to nominate people who I feel contribute a lot to Gentoo a= nd >>>> I have a lot of interaction with (ordered by name, not priority): >>>> [=E2=80=A6] >>>> flow >>> >>> I apologize for the late reply, and thank you for the nomination. I am >>> honored and accept. >>> >>> As many of you know, I am spending a lot of time on the EGO_SUM >>> situation, as it is one of the most critical issues to solve. >>> >>> I have used the last few days to carefully consider whether a seat on >>> the council is more harmful or beneficial to my efforts regarding >>> EGO_SUM. On the one hand, council work means I have less time to >>> improve the EGO_SUM situation. On the other hand, a seat in the >>> council increases the probability of positively influencing Gentoo's >>> future, also regarding EGO_SUM. >>> >> That's fine and it's great to see more people running! > > Excellent that we share this view. :) > > >> But with regard to EGO_SUM: you didn't appear at the meeting where we di= scussed >> your previous EGO_SUM proposal, > > Naively, as I am, I expected that the mailing list would be used for > discussion and that the council meeting would be used chiefly for > voting and intra-council discussion. And since the request to the > council to vote on a concrete proposal was preceded by a > multiple-week, if not month-long, mailing list discussion, I assumed > that my presence in the council meeting was optional. > > Had I known that my presence was required, or that the absence in the > meeting would be blamed on me afterward, I would have appeared if > possible. I'm not blaming you for anything. But you didn't speak in #gentoo-council before the meeting (a few days before IIRC) when we were discussing the problem, I pinged you during the meeting, and you didn't appear there afterwards. You also didn't seem to respond to the council decision (or non-decision) in that meeting either, unless I've missed it. It seems self-evident that discussion would happen in the meeting before voting...? What am I misunderstanding? We regularly discuss things before voting on them. Do you normally observe council meetings? I don't think what we did in this instance was at all unusual. (Also: there's the issue of whether or not the council should really be voting on overriding an eclass maintainer who would then be forced to keep something working they don't want to. mgorny raised that.) > > >> and questions remain unanswered on the >> ML (why not implement a check in pkgcheck similar to what is in Portage, >> for example)? > > On 2023-05-30 [1], I proposed a limit in the range of 2 to 1.5 MiB for > the total package-directory size. I only care a little about the tool > that checks this limit, but pkgcheck is an obvious choice. I also > suggested that we review this policy once the number of Go packages > has doubled or two years after this policy was established (whatever > comes first). > > But I fear you may be referring to another kind of check. You may be > talking about a check that forbids EGO_SUM in ::gentoo but allows it > overlays. My position on this has been consistent: a check is needed to statically determine when the environment size is too big. Copying the Portage check into pkgcheck (in terms of the metrics) would satisfy this. That is, regardless of raw size, I'm asking for a calculation based on the contents of EGO_SUM where, if exceeded, the package will not be installable on some systems. You didn't have an issue implementing this for Portage and I've mentioned this a bunch of times since, so I thought it was clear what I was hoping to see. I would also like (which is not what I was referring to here) some limit on the size, given that we already have a limit on the size of ${FILESDIR}, but this is less of a concern for me given it's bounded by the aforementioned environment size check. > > Intelligibly, EGO_SUM can be considered ugly. Compared to a > traditional Gentoo package, EGO_SUM-based ones are larger. The same is > true for Rust packages. However, looking at the bigger picture, > EGO_SUM's advantages outweigh its disadvantages. > Again, am on record as being fine with the general EGO_SUM approach, even if I wish we didn't need it, as I see it as inevitable for things like yarn, .NET, and of course Rust as we already have it. Just ideally not huge ones, and certainly not huge ones which then aren't even reliably installable because of environment size. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZJ6Skl8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZDfkgEA4yEKRXIJoYGTN4VrDzVdyYBfuMYEahC/oQ6G RDpa+j8A/R+KvoDYQRngXXyJCpcd+PBt9V6EHlCjBSqALRgEUlwP =uHuA -----END PGP SIGNATURE----- --=-=-=--