Permalink
Reply
On Friday, 30 August 2024 at 20:36:09 UTC, Dukc wrote:
>Mike Parker kirjoitti 30.8.2024 klo 17.30:
Thanks for elaborating.
> >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!
I can't speak for Steve, but I can tell you how I interpret what he said. He objected to the bitfields DIP for the same reason others did. Here, he was just expressing his opinion that this wasn't an issue he was willing to plant a flag over. He feels the consequences of it don't go beyond the feature itself and, since he thinks most people aren't going to use it anyway, he isn't going to waste energy fighting over it if it comes to that.
I don't see any disrespect of community opinion in that. And in the end, his input during the meeting on the DIP contributed to the outcome. He was essentially an advocate for the opposition to the proposal.
>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.
Again, I can't speak for Timon, but I can tell you how I interpret this. He was simply pointing out that editions give us more freedom to correct mistakes when we make them. Since editions are intended to encapsulate breaking changes, then we can undo in one edition any mistakes we made in a previous one. That doesn't mean we have a license to go wild, it just means we have more room to maneuver. I son't see anything unnerving about that.
Speaking for myself, I agree with him. Going a step further, I think editions will enable us to test new features without preview flags. We could add a feature in an edition and explicitly label it in the changelog as a preview feature, or maybe have a "preview edition" of preview features. I don't know, I'm just spitballing here. But the point is, if something isn't working, we have the flexibility to improve it or remove it in a future edition without worrying about breaking changes.
>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.
I want a better process because the old one wasn't working. Period. The DIP process itself was onerous and time consuming. I've seen it described as disrespectful of the DIP author's time. It had to change. I think the new process is much better.
The last piece was deciding on an established process for evaluating Walter's and Atila's DIPs and, since it came up in the meeting, controversial DIPs. I wanted that because I want to make sure that we have solid footing for any approval or rejection, regardless of opinion in the forums.
There has to be a balance here. It cannot be the case that forum opinion overrides maintainer decisions, and it must be the case that forum opinion is considered in the evaluations. I think the solution we've arrived at gets us close to that middle ground. Some of the members in any DIP review meeting will certainly represent opinions raised in the forums.
Like you said, we've got some respected voices on the team. We can add more voices with relevant experience or knowledge regarding specific DIPs when needed. Their role is to put the brakes on when they believe a proposal is flawed and should not go forward. If we then get to the point where they're satisfied that the flaws have been overcome, then the DIP can move forward on a solid basis.
Whether a DIP ends up approved or rejected after this process, the idea is that we'll have established a solid rationale either way.
Regarding contributor morale, we do consider it. Of course we do. That's what motivated us to go through Ucora's program, to expand our meeting team, to overhaul the DIP process, to start inviting stakeholders from the community to the planning sessions we have when we're discussing issues related to their interests.
It's why these days I push Walter and Atila for more verbosity in their rationales when they approve or reject a DIP. They are both very terse when they initially let me know their decision. I'm the one writing the announcement in the forums, so I want to make sure I understand the rationale fully and that it adequately addresses potential questions. I've learned the hard way that even uncontroversial decisions need a solid rationale that everyone can understand.
Anyway, I'm sorry that you feel we've been disrespectful of community opinion. I hope that over time the new process has a more positive impact.
