Re: [musl] Re: High-level C23 process requests

[Rich Felker <dalias@libc.org>]

On Wed, May 31, 2023 at 11:00:12PM +0200, Jₑₙₛ Gustedt wrote:
> Hello Rich,
> so now your are putting the blame on me, is that it?

I'm trying my best not to, despite being really frustrated.

> All the patches but for the 128 bit support are mandatory for C23.

OK.

> I separated this in several threads, because *you* wanted this. At
> several times I also posted a link to a git server that has all the
> patches in one branch. You knew what was coming and in which threads I
> planed to separate things.

Yes, and I still think multiple threads are fine, but what I had in
mind was a thread for each topic with posts in the thread evolving the
discussion of it, not branching for each individual patch in the set.
I never explicitly said that, though, and I'm not blaming you for not
knowing local etiquette for this list.

> Other than some years ago, I perceive this list as hostile and
> patronizing, at times not engaging in real discussions but boasting
> opinions that have been formed years ago and did not evolve. This is
> not a place where I want to be.
> 
> On the other hand I have the impression that we are almost finished. I
> will still take into account bona fide advice how to improve patches,
> evidently, if there are still things to comment. Then its up to you to
> take what you like and to reject what you don't. It seems that you are
> the boss here.

I think we're coming at this with very different goals. From what I
can gather (apologies if this turns out to be inaccurate), to you musl
looks like a place that's accessible to implement all the new things
C23 offers or allows, in a fairly straightforward way, that makes it
possible to test these things and get started with using new language
features you took part in shaping.

To myself and others in this community, though, there's mixed
sentiment towards new things. Already I've heard various comments to
the effect that folks think C23 is this big bad thing designed by
committee to impose new requirements nobody wants on implementations,
calls to boycott it, etc. That is very much NOT my view, but it's one
that comes up and that I'm stuck mediating. And new requirements often
do make it more difficult to preserve properties existing
users/community want and expect.

An important principle I go by is that a maintainer's most important
(technical) responsibility is to say no. This doesn't mean
unconditional no everywhere, but that no is the default, that
overriding existing project values and principles that a community has
come to expect requires compelling reasons and obtaining consensus. My
feeling during the whole C23 process has been that you've approached
this without any regard for that, pushing for whatever way of doing
things you would prefer, rather than what's most closely in line with
existing practices of the project you're trying to make upstreamable
changes to.

I very much appreciate and respect your work on the standardization
process and your support for and contributions to musl, but I'd be
lying if I said this present engagement isn't really frustrating to
me. As you've said, though, I think it's "almost finished", and I'll
do my best to focus on technical matters (vs style etc.) of the parts
that are appropriate and needed C23 support.

Rich