Mike Parker kirjoitti 30.8.2024 klo 17.30:
On Friday, 30 August 2024 at 13:49:09 UTC, Dukc wrote:
I can't understand how that's the impression you get from this. I was
looking for a solution that would find a balance between the
"dictatorial" aspect of approving DIPs authored by Walter and Atila and
the input of the community when a DIP is unpopular.
I think what we've settled on will help with that. Had something like
this been in place when that safe-by-default DIP was proposed, I expect
the outcome would have been very different. It wouldn't have made it to
approval without modification. That's the point here.
Right, you do aknowledge the problem and are making honest effort to
solve it, yet I still posted criticism almost as if you didn't. I
certainly owe details on what about the summary worries me. Let's go.
First off,
> Steve didn't think the bitfields DIP was as controversial as the
`extern(C)` functions being safe by default, which was the source of the
blowup over that DIP, because not many people were using bitfields. He
thought Walter's concerns were a non-issue as nobody would care. The
penalty would be that we'd just inherit all of C's problems with bitfields.
There's nothing inherently wrong in this. Steve is probably right, it
isn't _as_ controversial as the safe-by-default C functions. But saying
that it would lead to _just_ inheriting C's bitfield problems is what
worries me. It likely wouldn't result in a wave of ragequits of D, but
that doesn't mean it would have no effect on general impression of the
foundation. On positive note though, you _did_ decide revising it more
before proceeding so there still is progress!
Second, this:
> He said that going forward, accepting a bad DIP would be less
consequential than it had been in the past once we had editions. In the
worst case, we'd have one thing more to maintain in an intermediate
edition before it was fixed. Maybe that was a calculation we could take
into consideration. Átila said that was a good point.
You should be at least as worried about the damage to contributor morale
on a bad decision as about the damage to the language. Editions do good
job limiting the latter but not the former. If you accept that you can
see why this attitude is unnerving.
Also, the general idea that you want a better process to avoid such
failures, feels like you're using it as a substitute to simply raising
the bar of going against community consensus. This also deserves
elaboration.
We all know that when Walter starts pursuing an idea he just won't hear
"no". It's just his nature. Sometimes it's a virtue - D exists because
Walter refused to believe he couldn't implement a C compiler, and also
the countless naysayers when he still was working alone on D. It's
probably overwhelmingly difficult for him to seriously question those
parts of his DIPs he considers central to his visions. Meaning I
shouldn't have written "especially Walter" in my last post - sorry about
that.
But, the old process already has Átila as the gatekeeper. I think Átila
is more capable than Walter to stop and reconsider, and even if he isn't
his fixations are different from Walter's. Therefore when the community
is virtually unanimously screaming NO NO NO it ought to make him
extremely unlikely to apply the green stamp. Or at least to correct his
attitudes about that after making one bad decision, without needing a
change to the process.
That said, I did miss a few paragraphs when I read the summary. When I
check it again, it seems the new process isn't that heavy (discuss it on
meeting if unpopular). Also it does address the problem - the usual
participants of the meeting are a reasonable representation of the
community so as long as you listen to the participants it should work.
So I agree the process revision sounds good, even if in my view you
shouldn't have had to do it.
