Posted to gentoo-dev@ since we are now entering a technical discussion again. For those who did not follow gentoo-project@, the previous posts include: https://marc.info/?l=gentoo-project&m=168918875000738&w=2 https://marc.info/?l=gentoo-project&m=168881103930591&w=2 On 12/07/2023 21.28, Alec Warner wrote: > On Wed, Jul 12, 2023 at 12:07 PM Florian Schmaus wrote: >> Apologies for not replying to everyone individually. >> >> I thank my fellow council candidates who took the time to reply to this >> sensitive and obviously controversial matter. I understand that not >> everyone feels comfortable taking a stance in this discussion. >> >> I asked the other council candidates about their opinion on EGO_SUM. >> Unfortunately, some replies included only a rather shallow answer. A few >> focused on criticism of my actions and how I approach the issue. Which >> is obviously fine. I read it all and have empathy for everyone who feels >> aggravated. You may or may not share the complaints. But let us focus on >> the actual matter for a moment. >> >> Even the voices raised for a restricted reintroduction of EGO_SUM just >> mention an abstract limit [1]. A concrete limit is not mentioned, >> although I asked for it and provided my idea including specific limits. >> Not knowing the concrete figures others have in mind makes it difficult >> to find a compromise. For example, a fellow council candidate postulated >> that it would be quicker for me to implement a limit-check in pkgcheck >> than discuss EGO_SUM. I wish that were the case. Unfortunately it is >> potentially not trivial to implement if we want such a check to be >> robust. But even worse, a specific limit must be known before >> implementing such a check. And we currently have none. > > I think my concern here is that I don't expect the Council to really > 'vote on a specific limit.' The limit is an implementation detail, it > can change, it shouldn't require a council vote to change. > > So my advice is "pick something reasonable that you think holds up to > scrutiny, and implement with that" and "expect the limit to change, > either because of the scrutiny, or because it might change in the > future" and implement your check accordingly (so e.g. the limit is > easily changeable.) Please find below why this may not be enough. >> But the real crux of an EGO_SUM reintroduction with a limit is the >> following. Either the limit is too restrictive, and most packages are >> affected by it and can not use EGO_SUM, which ultimately only >> corresponds to the current state. Or the limit only affects a fraction >> of the packages, so you should not bother having a limit. > > Again the idea is there is already a limit ( the aforementioned > environment limit ) and one of the goals is to have a QA check that > says your ebuild is approaching that limit so you can do something > productive about it, as well as to avoid ebuilds that are not > installable. So just implement that. If you need a number, I think > "90% of the env limit" is defensible (but again, any reasonable number > will do fine.) EGO_SUM affects two dimensions that could be limited/restricted: A) the process environment, which may run into the Linux kernel environment limit on exec(3) B) the size of the package directory, where EGO_SUM affects the size of ebuilds and the Manifest I would be happy to put in any effort required to implement A) in pkgcheck, as I did for portage, if this check is the only thing that keeps us from reintroducing EGO_SUM. Unfortunately, some argue that we need to limit B). Much of the effort I put into researching the EGO_SUM situation was analyzing how EGO_SUM's impact on package-directory size affects Gentoo. The result of the analysis strongly indicates that rather large package-directories can be sustained by ::gentoo in the foreseeable future. Especially since we are only talking about ~250 EGO_SUM packages currently, and a significant fraction of those packages will not have enormous package directories. And I also suggested that the policy is reconsidered at least every two years or once the number of EGO_SUM packages has doubled (whatever comes first). My investigation of the history of EGO_SUM's deprecation has not surfaced any technical issue which justified EGO_SUM's deprecation with regard to B). It appears that technical issues do not drive the desire to limit B), but by esthetic preferences, which are highly subjective. A), however, is a different beast. There is undeniably a kernel-enforced limit that we could hit due to an extremely large EGO_SUM (among other things). However, the only bug report I know that runs into this kernel limit was with texlive (bug #719202). The low number of recorded bugs caused by the environment limit matches with the fact that even the ebuild with the most EGO_SUM entries that I ever analyzed, app-containers/cri-o-1.23.1 (2022-02-16) with 2052 EGO_SUM entries, does *not* run into the environment limit. >> The deprecation of EGO_SUM was and is unnecessary, a security issue, and >> was almost wholly *not* driven by technical problems. EGO_SUM should be >> re-instated. >> >> I know that some think likewise. I also know that others disagree. The >> latter group includes some prominent and visible Gentoo developers. >> People to whom I am thankful for their work on Gentoo and to whom Gentoo >> owes a lot. However, it is unclear what the majority of Gentoo >> developers thinks. I could very well be that the consensus amongst >> Gentoo developers agrees with some of my fellow council candidates and >> would like to keep the current state. It would be great if we find that >> out. If we had a mechanism to perform a non-binding opinion poll amongst >> Gentoo developers, and if that poll turns out that the consensus is to >> keep EGO_SUM deprecated, then I could save myself a lot of time and effort. > > I'm confused why you are asking about the 'consensus amongst > developers' and then ask the council to vote. If I knew that the majority of Gentoo developer's is fine with the deprecation of EGO_SUM, then I would not put in effort in re-instating EGO_SUM. >> However, as of now, my conscience demands that I try to improve this >> situation for the sake of our users. In a previous mail, I wrote that I >> seek closure by asking the council to vote on that matter. And I will, >> of course, accept any outcome of that vote. > > My impression of the situation is that: > - Currently if asked, the council would likely vote no. > - They have requested you implement a QA check with a limit, and if > you did that, many swing voters would vote yes. > > My guidance from above is "implement the check with some reasonable > limit" to unblock your swing voters, so they vote yes... > > We don't need everyone to vote on what the limit is ..it's just > wasting time IMHO. It is not about everyone voting on that matter. It is about asking everyone of their opinion on that matter, in a non-binding opinion poll where multiple options can be ranked [1]. Chances are that this would surface the consensus amongst Gentoo developers, and ideally, the Council would take the result of the poll into consideration when voting on that matter. - Flow 1: I think that it is probably trivial to re-purpose our current voting infrastructure to perform opinion poll using the condorcet method.