From: "Michał Górny" <mgorny@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
Date: Fri, 08 Jan 2021 19:31:01 +0100 [thread overview]
Message-ID: <ec9b2f0b6b924f68f3a643a03d783dbc5131bfbe.camel@gentoo.org> (raw)
In-Reply-To: <2c5d738a-04f7-94a7-d2ed-1983743dcef6@gentoo.org>
On Fri, 2021-01-08 at 19:10 +0100, Thomas Deutschmann wrote:
> On 2021-01-08 18:06, Mike Gilbert wrote:
> > I disagree with your premise: I argue that the eclass is not "broken",
> > and the code works as designed. You just don't like aspects of its
> > design.
>
> Several people, not just me... *users*, other devs like robbat2 and
> antarus, all with experience in maintaining multiple systems not just as
> a hobby, have expressed that the current design has a flaw.
They did. What you're neglecting to repeat is that they've also
indicated that your proposed design is flawed as well. You're
conflating 'design A is flawed' into 'design B is better', while they
really said 'both design A and B are flawed'.
> I got feedback from other devs representing a large group in Gentoo and
> they all agree on the problem. They haven't spoken up yet because they
> don't care because the way how they use Gentoo is stateless.
>
> So why the hell is it acceptable for a small group (you and mgorny,
> Michael told me already last year that he will be fine with an opt-in
> change and I assume his opinion hasn't changed) to cause problems for
> another group just because you don't want to acknowledge the problem?
So what's you're basically saying is that there are people who like
behavior A, people who like behavior B and people who don't care.
Somehow you manage -- without any hard evidence -- to claim that people
who dislike the current behavior are more numerous than the people who
like the current behavior, and also implicitly count people who don't
care towards them (why?). Even if you managed to prove that (how?), is
this really a popularity contest?
The current behavior has been the default for 1.5 years. There are
ebuilds that literally depend on it. If you are going to change that,
then you need to prove that 1) your proposed solution is much better for
the vast majority of Gentoo users (again, how?), and 2) that the benefit
from the change in behavior outweighs its costs. And given that you've
pretty much admitted that the majority probably 'does not care', then 2)
is not met.
> Even soap, not sure if he has spoken for himself or as QA lead, has
> acknowledged in this thread that we need a mechanism to disable this
> behavior.
>
> Is it really not possible to solve this technical problem? Do we have to
> escalate and need a vote or something to replace entire GLEP 81 with
> something new just because a group believes there is no flaw and
> everyone else having problems are doing things wrong so this group is
> rejecting any attempts to address the problem?
Again, I don't understand why you continue escalating this. I have
already indicated that I'm fine with adding an option to disable this,
given that 1) the current behavior remains the default, and 2) people
are given big fat warning that they are now responsible for updating
their users (and ideally 3) the eclass tells user how to update
the user). I've just asked for the option to override values via
make.conf goes first since that is the preferred solution that doesn't
destroy the foundations of GLEP 81.
floppym has indicated an interest in this, so I've presumed he's going
to submit an updated patch to the ml.
--
Best regards,
Michał Górny
next prev parent reply other threads:[~2021-01-08 18:31 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-04 1:35 [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default Thomas Deutschmann
2021-01-04 2:41 ` Mike Gilbert
2021-01-04 3:17 ` Alec Warner
2021-01-04 3:18 ` Michael Orlitzky
2021-01-04 14:46 ` Thomas Deutschmann
2021-01-04 15:24 ` Michael Orlitzky
2021-01-04 15:55 ` David Seifert
2021-01-04 16:18 ` Thomas Deutschmann
2021-01-04 16:28 ` Michał Górny
2021-01-04 16:30 ` Thomas Deutschmann
2021-01-04 16:34 ` Thomas Deutschmann
2021-01-04 16:38 ` Michał Górny
2021-01-04 16:50 ` Thomas Deutschmann
2021-01-04 16:56 ` Michał Górny
2021-01-04 16:56 ` Mike Gilbert
2021-01-04 16:54 ` Mike Gilbert
2021-01-04 7:32 ` Robin H. Johnson
2021-01-04 16:45 ` [gentoo-dev] " James Cloos
2021-01-04 18:07 ` Michael Orlitzky
2021-01-04 18:20 ` Michał Górny
2021-01-04 18:38 ` Michael Orlitzky
2021-01-04 18:23 ` Thomas Deutschmann
2021-01-04 18:27 ` Michael Orlitzky
2021-01-04 18:32 ` Thomas Deutschmann
2021-01-04 9:23 ` [gentoo-dev] " Michał Górny
2021-01-04 14:05 ` Thomas Deutschmann
2021-01-04 16:10 ` Mike Gilbert
2021-01-04 16:14 ` Michał Górny
2021-01-04 16:20 ` Thomas Deutschmann
2021-01-08 18:11 ` Fabian Groffen
2021-01-08 18:14 ` Michał Górny
2021-01-08 18:23 ` Thomas Deutschmann
2021-01-08 18:32 ` Michał Górny
2021-01-08 15:48 ` Thomas Deutschmann
2021-01-08 16:03 ` Mike Gilbert
2021-01-08 16:29 ` Thomas Deutschmann
2021-01-08 16:50 ` Mike Gilbert
2021-01-08 17:06 ` Mike Gilbert
2021-01-08 18:10 ` Thomas Deutschmann
2021-01-08 18:31 ` Michał Górny [this message]
2021-01-08 19:15 ` Mike Gilbert
2021-01-08 17:16 ` Michał Górny
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=ec9b2f0b6b924f68f3a643a03d783dbc5131bfbe.camel@gentoo.org \
--to=mgorny@gentoo.org \
--cc=gentoo-dev@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