Florian Schmaus <flow@gentoo.org> writes:

[CCing williamh@ as go-module.eclass & dev-lang/go maintainer.]

> I like to ask the Gentoo council to vote on whether EGO_SUM should be
> reinstated ("un-deprecated") or not.
>
> EGO_SUM is a project-comprehensive matter, as it affects not only
> Go-lang packaging but also the proxy-maint and GURU
> projects. Furthermore, as I have mentioned in my previous emails, the
> deprecation of EGO_SUM has a significant negative impact on our users
> and is, therefore, a global Gentoo issue.
>
> Asking for council involvement should be a last resort and only be
> done in essential conflicts. But, unfortunately, I was unable to
> convince the relevant maintainer with arguments that the deprecation
> of EGO_SUM is harmful. And this matter is significant enough to
> proceed with this.

My feeling on this is that this proposal isn't yet complete enough
for the council to assess. In the various previous discussions, the need
for _some_ limit to be implemented (derived from EGO_SUM) was clear from
the QA team and others.

Voting on the matter now would be reopening the issue which led EGO_SUM
to be deprecated in the first place, with only a partial mitigation
(the Portage warning).

Any such limit should be supported by pkgcheck, allow using EGO_SUM
for most packages, but exclude the pathological cases which we're
unlikely to want in ::gentoo.

(Limit-per-ebuild rather than per-package is one option of many,
too.)

>
> Most voices on the related mailing-list threads expressed support for
> reinstating EGO_SUM. At least, that is my impression. While the
> arguments used to deprecate EGO_SUM were mostly of esthetic nature.
>
> I want to state what should be common sense. Namely, asking for a
> democratic vote is not a personal attack against any involved
> person.
> [...]

I agree this is an important issue that affects the practicality
of using Gentoo for some, and for contributing to Gentoo to others.

>
> On 17/04/2023 09.37, Florian Schmaus wrote:
>> [original msg snipped]