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