public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Sam James <sam@gentoo.org>
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	[thread overview]
Message-ID: <87jzvl2vzh.fsf@gentoo.org> (raw)
In-Reply-To: <5b5e5a30-6fcc-7a9d-6c91-67d9a6a5c560@gentoo.org>

[-- Attachment #1: Type: text/plain, Size: 4861 bytes --]


Florian Schmaus <flow@gentoo.org> 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 <flow@gentoo.org> writes:
>>> On 17/06/2023 10.37, Arthur Zamarin wrote:
>>>> I also want to nominate people who I feel contribute a lot to Gentoo and
>>>> I have a lot of interaction with (ordered by name, not priority):
>>>> […]
>>>> 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 discussed
>> 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.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]

  reply	other threads:[~2023-06-30  8:30 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2ZKWN4KF.MKEFFMWE.LGPKYP47@RTL7EJXF.RN4PF6UF.MDFBGF3C>
     [not found] ` <be450641-94ff-a0d9-51da-3a7a3abcc6c7@gentoo.org>
     [not found]   ` <b7309a3f-2980-b390-a16a-0518cce1da75@gentoo.org>
     [not found]     ` <87y1k33aoy.fsf@gentoo.org>
2023-06-30  8:15       ` [gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.) Florian Schmaus
2023-06-30  8:22         ` Sam James [this message]
2023-06-30  9:38           ` Tim Harder
2023-06-30 11:33             ` Eray Aslan
2023-07-03 10:17               ` Florian Schmaus
2023-07-04  7:13                 ` Tim Harder
2023-07-04 10:44                   ` Gerion Entrup
2023-07-04 21:56                     ` Robin H. Johnson
2023-07-04 23:09                       ` Oskari Pirhonen
2023-07-05 18:40                         ` Gerion Entrup
2023-07-05 19:32                           ` Rich Freeman
2023-07-06  2:48                           ` Oskari Pirhonen
2023-07-06  6:09                   ` Zoltan Puskas
2023-07-06 19:46                     ` [gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open Hank Leininger
2023-07-08 20:49                     ` [gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.) Sam James
2023-07-03 10:17           ` Florian Schmaus
2023-07-03 11:12             ` [gentoo-dev] EGO_SUM Ulrich Mueller
2023-07-08 21:21             ` [gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.) Sam James
     [not found]     ` <cdf5ddb7-8f65-74cf-5594-3e3eec86c915@gentoo.org>
     [not found]       ` <1913d3c2-5f54-acea-0ed3-930371ea1884@gentoo.org>
     [not found]         ` <CAAr7Pr9+zq2NV=7zhj5e+4LWOmNavCrfMstNTqkthk5uxQVNtg@mail.gmail.com>
2023-07-14  7:14           ` [gentoo-dev] Re: Flow's Manifesto and questions for nominees (was: " Florian Schmaus
2023-07-14  7:33             ` Sam James
2023-07-14  8:19               ` Sam James
2023-07-14  9:07               ` Florian Schmaus
2023-07-14  8:39             ` [gentoo-dev] Re: Flow's Manifesto and questions for nominees Ulrich Mueller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87jzvl2vzh.fsf@gentoo.org \
    --to=sam@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox