[gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.)

[Florian Schmaus <flow@gentoo.org>]

[-- Attachment #1.1.1: Type: text/plain, Size: 3981 bytes --]

[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.


> 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.

However, as stated before [2], this is not a viable approach. One reason 
why it is not practicable is auditability.


> The blocker is not a council seat, it's about addressing people's
> concerns...

Unfortunately, it appears that I am terrible at convincing everyone that 
the deprecation of EGO_SUM was a mistake. I tried to respond to every 
concern. Often, the response included arguments based on factual data. 
But eventually, I would only expect to convince some, as the EGO_SUM 
question touches the subjective realm of style.

I know that the EGO_SUM situation and the resulting discussion grew huge 
and left many understandably bored or confused, which then turned away. 
But that is a pity because it is a relevant discussion for Gentoo's 
long-term success.

The bottom line is that the EGO_SUM discussion yielded no evidence or 
even a slight indication that EGO_SUM was deprecated based on technical 
issues. Instead, it appears that EGO_SUM was deprecated because some 
deemed it unaesthetic.

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.

- Flow


1: https://marc.info/?l=gentoo-dev&m=168546196902731 
<25308876-7ac4-8c90-8641-1034cc67c6b0@gentoo.org>
2: https://marc.info/?l=gentoo-dev&m=168569387514376 
<012fa74d-2910-ea90-6008-26cc23604d2f@gentoo.org>

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 17273 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]