[gentoo-dev] Re: Flow's Manifesto and questions for nominees (was: Re: [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: 7592 bytes --]

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 <flow@gentoo.org> 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.

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