On 28/06/2023 16.46, Sam James wrote:
Florian Schmaus <f...@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): […] flowI 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.
- Flow1: https://marc.info/?l=gentoo-dev&m=168546196902731 <25308876-7ac4-8c90-8641-1034cc67c...@gentoo.org> 2: https://marc.info/?l=gentoo-dev&m=168569387514376 <012fa74d-2910-ea90-6008-26cc23604...@gentoo.org>
OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
