From: "Michał Górny" <mgorny@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Cc: Matt Turner <mattst88@gentoo.org>, Sam James <sam@gentoo.org>,
council@gentoo.org, William Hubbs <williamh@gentoo.org>
Subject: Re: [gentoo-dev] Re: EGO_SUM
Date: Fri, 28 Apr 2023 16:34:18 +0200 [thread overview]
Message-ID: <aaa71678f0962df3c0754d55ab6137d057243aaa.camel@gentoo.org> (raw)
In-Reply-To: <398aa54d-1138-a28d-00fd-a6f6faa16b0c@gentoo.org>
On Fri, 2023-04-28 at 08:59 +0200, Florian Schmaus wrote:
> On 27/04/2023 14.54, Michał Górny wrote:
> > On Thu, 2023-04-27 at 09:58 +0200, Florian Schmaus wrote:
> > > Disk space is cheap.
> >
> > No, it's not. Gentoo supports more hardware than your average PC with
> > beefy hard drive and/or possibility of installing one. Let's not forget
> > that you need a ::gentoo checkout even on a system running purely
> > on binary packages.
>
> You are right. Gentoo supports a broad range of hardware in many
> dimensions, e.g., architecture, release date, and composition.
>
> You seem to suggest that are Gentoo systems that can not handle the
> additional disk space consumption of EGO_SUM Go-packages?
>
> I can not imagine systems that are able to deal with the ~500 MiB
> ::gentoo repository, but would break if the same repository would
> contain 100 additional Go-packages with 200 KiB each.
>
> Even under a "worst-case" assumption, where we would have 256
> Go-packages with each having a 1 MiB package-directory size, any system
> that can handle the current state of ::gentoo should be able to take the
> additional 256 MiB (+ metadata).
That's the slippery slope of exponential growth. If every developer
thought "oh, worst case it'll grow only 10%"...
There's roughly 19k packages in Gentoo. Go packages constitute only
a small number of them, yet maintainers of these packages seem to assume
it's fine if they take up a significant portion of disk space. That's
not fair at all.
In fact, I'm pretty sure I ground some numbers in the previous thread.
> >
> I am only pursuing the modest request to legitimize any decision
> regarding EGO_SUM by a democratic vote.
>
> As far as I can tell, there was never a democratic vote regarding
> EGO_SUM. But please correct me if I am wrong.
Since when are eclass design issues "legitimized" by "a democratic
vote"? In the best case, they are handled via rough consensus.
In the worst, a single person can't stand a decision and bothers
everyone until they let them have their way.
Open source is not a democracy, it's volunteer effort. People dedicate
their free time and do their best. If you want something done, you have
to either do it yourself (and do it right!) or convince someone to do
it. You don't overturn maintainers by "democratic votes", that's
actually how you shatter open source community and make volunteers stop
contributing.
Believe me, I've made enough bad decisions to know that now.
> And I never said that I believe in representing the majority's opinion.
> That said, I prefer to have this voted on by an all-developer vote than
> a council vote. Then we would know what the majority voted for. Is that
> possible?
There's the General Resolution but it's supposed to be used only to
override Council decisions, so you should go with a Council vote first.
I don't believe this is a hill worth dying on but if you insist...
*shrug*. I just wish you'd actually listen to people and put some real
effort to reach a compromise/consensus rather than pushing your narrow
solution through with no regard for consequences.
--
Best regards,
Michał Górny
next prev parent reply other threads:[~2023-04-28 14:34 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-17 7:37 [gentoo-dev] EGO_SUM Florian Schmaus
2023-04-17 9:28 ` [gentoo-dev] EGO_SUM Anna (cybertailor) Vyalkova
2023-04-27 18:00 ` William Hubbs
2023-04-27 18:18 ` David Seifert
2023-04-24 16:11 ` Florian Schmaus
2023-04-24 20:28 ` Sam James
2023-04-24 22:52 ` Alexey Zapparov
2023-04-26 15:31 ` Florian Schmaus
2023-04-26 16:12 ` Matt Turner
2023-04-26 19:31 ` Andrew Ammerlaan
2023-04-26 19:38 ` Chris Pritchard
2023-04-26 20:47 ` Matt Turner
2023-04-27 7:58 ` Florian Schmaus
2023-04-27 9:24 ` Ulrich Mueller
2023-04-28 6:59 ` Florian Schmaus
2023-04-27 12:54 ` Michał Górny
2023-04-27 23:12 ` Pascal Jäger
2023-04-28 0:38 ` Sam James
2023-04-28 4:27 ` Michał Górny
2023-04-28 5:31 ` Sam James
2023-04-28 6:59 ` Florian Schmaus
2023-04-28 14:34 ` Michał Górny [this message]
2023-05-02 19:32 ` Florian Schmaus
2023-05-02 19:38 ` Sam James
2023-04-29 22:34 ` Robin H. Johnson
2023-04-27 21:16 ` Sam James
2023-05-02 19:32 ` Florian Schmaus
2023-05-02 19:45 ` Sam James
2023-05-08 7:53 ` Florian Schmaus
2023-05-08 12:03 ` Michał Górny
2023-05-22 7:14 ` Florian Schmaus
2023-05-02 20:04 ` Matt Turner
2023-05-08 7:53 ` Florian Schmaus
2023-04-26 20:51 ` Sam James
2023-05-30 15:52 ` Florian Schmaus
2023-05-30 16:30 ` Anna (cybertailor) Vyalkova
2023-05-31 5:02 ` Oskari Pirhonen
2023-05-30 16:35 ` Arthur Zamarin
2023-05-31 6:20 ` Andrew Ammerlaan
2023-05-31 8:40 ` Ryan Qian
2023-05-31 9:06 ` Arsen Arsenović
2023-05-31 6:30 ` pascal.jaeger leimstift.de
2023-06-01 4:00 ` William Hubbs
2023-06-02 8:17 ` Florian Schmaus
2023-06-02 8:31 ` Michał Górny
2023-06-09 10:07 ` Florian Schmaus
2023-06-01 19:55 ` [gentoo-dev] EGO_SUM William Hubbs
2023-06-02 7:13 ` Joonas Niilola
2023-06-02 18:06 ` William Hubbs
2023-06-02 18:42 ` Joonas Niilola
2023-06-09 10:07 ` Florian Schmaus
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=aaa71678f0962df3c0754d55ab6137d057243aaa.camel@gentoo.org \
--to=mgorny@gentoo.org \
--cc=council@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
--cc=mattst88@gentoo.org \
--cc=sam@gentoo.org \
--cc=williamh@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