From: Alec Warner <antarus@gentoo.org>
To: gentoo-project@lists.gentoo.org
Subject: Re: Flow's Manifesto and questions for nominees (was: Re: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.)
Date: Wed, 12 Jul 2023 12:28:22 -0700 [thread overview]
Message-ID: <CAAr7Pr9+zq2NV=7zhj5e+4LWOmNavCrfMstNTqkthk5uxQVNtg@mail.gmail.com> (raw)
In-Reply-To: <1913d3c2-5f54-acea-0ed3-930371ea1884@gentoo.org>
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.)
>
> 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.)
>
> 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.
The council is not all developers, you just need the council to approve it.
>
> 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.
-A
>
> - Flow
>
>
> 1: Sorry if I have missed something. If so, then please let me know.
next prev parent reply other threads:[~2023-07-12 19:28 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-15 16:05 [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours Roy Bamford
2023-06-17 8:37 ` Arthur Zamarin
2023-06-17 16:23 ` Toralf Förster
2023-06-18 19:46 ` Ionen Wolkens
2023-06-21 18:46 ` Sam James
2023-06-21 21:06 ` Ulrich Mueller
2023-06-24 18:22 ` John Helmert III
2023-07-08 22:23 ` John Helmert III
2023-06-25 5:08 ` Joonas Niilola
2023-06-25 8:51 ` Andreas K. Huettel
2023-06-25 23:18 ` Matt Turner
2023-06-26 13:46 ` Michał Górny
2023-06-27 9:31 ` David Seifert
2023-06-27 13:35 ` Jakov Smolić
2023-06-28 9:51 ` Florian Schmaus
2023-06-28 14:46 ` Sam James
2023-07-08 10:10 ` Flow's Manifesto and questions for nominees (was: Re: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.) Florian Schmaus
2023-07-08 12:33 ` Michał Górny
2023-07-08 21:29 ` Sam James
2023-07-09 3:21 ` Michał Górny
2023-07-08 20:22 ` [gentoo-project] Re: Flow's Manifesto and questions for nominees Ulrich Mueller
2023-07-08 21:29 ` Flow's Manifesto and questions for nominees (was: Re: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.) David Seifert
2023-07-08 22:50 ` John Helmert III
2023-07-09 14:21 ` Matt Turner
2023-07-12 19:06 ` Florian Schmaus
2023-07-12 19:28 ` Alec Warner [this message]
2023-07-14 7:14 ` Florian Schmaus
2023-07-14 7:33 ` Sam James
2023-07-14 8:19 ` Sam James
2023-06-30 16:39 ` [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours Andreas Sturmlechner
2023-07-01 22:42 ` David Seifert
2023-06-17 14:41 ` Florian Schmaus
2023-06-17 14:58 ` Arthur Zamarin
2023-06-17 16:19 ` James Le Cuirot
2023-06-19 13:44 ` Pacho Ramos
2023-06-20 10:16 ` Florian Schmaus
2023-06-21 17:32 ` Arsen Arsenović
2023-06-21 7:05 ` Guilherme Amadio
2023-06-23 19:53 ` Patrick McLean
2023-06-24 21:58 ` Conrad Kostecki
2023-06-29 13:28 ` Mike Gilbert
2023-06-30 6:35 ` Robin H. Johnson
2023-06-30 7:24 ` Maciej Barć
2023-06-30 8:46 ` Andrew Ammerlaan
2023-06-30 8:56 ` Hans de Graaff
2023-06-30 10:21 ` Mike Pagano
2023-06-30 12:30 ` David Abbott
2023-06-30 15:18 ` Jimi Huotari
2023-06-30 16:10 ` Roy Bamford
2023-06-30 20:29 ` Alfredo Tupone
2023-07-01 0:04 ` Rich Freeman
2023-07-03 20:02 ` Marek Szuba
2023-06-30 21:59 ` [gentoo-project] Re: [gentoo-dev-announce] " Patrick Lauer
2023-07-08 18:06 ` Arthur Zamarin
2023-07-09 3:36 ` Michał Górny
2023-07-09 14:09 ` Matt Turner
2023-07-09 17:47 ` [gentoo-project] " Ulrich Mueller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAr7Pr9+zq2NV=7zhj5e+4LWOmNavCrfMstNTqkthk5uxQVNtg@mail.gmail.com' \
--to=antarus@gentoo.org \
--cc=gentoo-project@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox