Hi Lukas,

On Mon, Aug 26, 2024 at 12:19:20PM +0200, Lukas Märdian wrote:
> Surveying the wrong set of people will lead to unusable data. Henry Ford
> summarized this nicely some 100 years ago, when asked about customer input
> in the development of the Ford Model T automobile: "If I had asked people
> what they wanted, they would have said faster horses."

You're continuing to confirm my pre-existing view that netplan infantilizes
it's users as you're applying the same thinking to the entire Debian
community here.

In my mind Debian is an operating system for experts (perhaps
aspiring). Treating users like they are going to hurt themselves if we
listen to them is not acceptable conduct in this community in my opinion.

> IMO, the data is already there in all the different (Mini-)DebConf and
> email discussion over the past couple of year. If people were just happy
> with /etc/network/interfaces, we wouldn't have this discussion year after
> year after year..

The "data" sources you mention are severely biased in one way or
another. You complain about unusable data above only to suggest even more
obviously unusable data here. I don't find this very convincing.

Aside: I found reading up on (congitive) biases to help put my thinking on
a more solid foundation. Can recommend.

> At DebConf in Busan we discussed that we should set some timeline onto
> ourselfes in finding consensus (some 6-8 weeks, e.g. end of September), as
> changing the network stack isn't a small feat and we should do it early in
> the cycle, so there's plenty of time to have it properly tested. So there
> should be at least a little sense of urgency, even if Trixie'S release
> dates are not yet announced.

I don't agree with that timeframe. Not all of us get to work on Debian
full-time let alone attend all our far flung events.

> I'm afraid all of this will just further delay the decision making for
> another year/Debian release.

So what? So far you're the only one complaining about this. What skin do
you have in the game if we don't move forward on this other than having an
obviously biased interest in having netplan be a standard?

If Santiago was to complain about having to maintain ifupdown for another
cycle that would actually carry some weight for me, but then I'd be happy
to help share that load. Would you do the same?

IMO if you're not ready to share *that* burdon that says something I don't
think I have to explain to readers.

> PS: I'm dissapointed by the fact that you keep your counter proposal secret

Lukas. For everyone not on your private email chain already there is
essentially no difference between this and not posting your proposal
publically so please consider that the same argument applies to the way
you've chosen to run this discussion.

To be clear: I'm also disappointed you've once again decided to take this
public discussion private for no good reason. Do you have something to
hide?

> and are unwilling to elaborate on your strong NACK on raising Netplan's
> "Priority". 

I'll be happy to elaborate at the time mentioned before: when you post the
conclusion of the private thread publicly. This is IMO a proportional
response to your course of action in taking the discussion private in the
first place.

> It's really hard for me to take it serious this way. I've researched this
> topic for well over a year now, discussed it with people involved and
> tried to bring reasonable options to the table. Explicitly asking for any
> additional options, so we can refine/merge and find consesns.  It almost
> feels like you'd be mostly interested in just delaying/blocking progress
> here.. :-(

I promise you I'm not intentionally, but I do recognize that it may be a
side-effect. Likewise I feel like you're just interested in pushing this
through as quickly as possible.

Consider that for you time is an ally, being employed to work on this
(AFAICT?). For the rest of us not so much. Debian is a primarily a
volunteer project. Please stop pushing for doing things faster.

Thanks,
--Daniel

Attachment: signature.asc
Description: PGP signature

Reply via email to