On 1/10/2024 2:40 AM, Paolo Invernizzi wrote:
> Let's come back to pragmatism:
> - everyone thinks DIP1038e is far better than DIP1027
> - you are not convinced, but hey, we are human being, maybe you are wrong.

Please save that thought for the other thread.

On Tuesday, 9 January 2024 at 21:26:30 UTC, H. S. Teoh wrote:
> On Tue, Jan 09, 2024 at 07:32:10PM +0000, GrimMaple via Digitalmars-d wrote:
>> [...]
>
> Well, I *do* have a long track record of contributing to D. I've had not a small number of PRs merged into Phobos and a few in DMD.  I was even given commit access to Phobos (and still have it, though I haven't used it in years) and for a time put a lot of effort into reviewing and merging PRs.
>
> [...]

Pretty much how it was 3yrs ago. I even wrote about the lack of soft skills needed to grow the community among the leadership [1](https://aberba.com/posts/2020-12-09-why-i-still-use-d). Unfortunately not much has changed.

I among others used to complain a lot about the above mentioned issues but it only stressing us all out lol.

On Wednesday, 10 January 2024 at 15:32:11 UTC, Guillaume Piolat wrote:
> On Wednesday, 10 January 2024 at 13:30:02 UTC, Paolo Invernizzi wrote:
>>
>> Let's start from a common point: we all care about D, let's try to be positive and find out if there's a good way to move forward and solve the kind of problems that we are facing with this situation.
>
> Exactly.
>
>
>> I honestly ask, you have suggestions?
>
> Yes, but I don't think I would be more relevant than what the DLF say itself.
>
> What I observe is that we've given ample space to a discourse that fantasize a horrible destiny for D, and sometimes just plain impoliteness, while from where I stand all kinds of issues go away over time, 50 of my 64 Buzilla entries have been solved (and the other don't matter), and in D industry meetings some have nothing to ask for! And everyone seems to be liking D. How do you reconcile that?

Everyone like D, and everyone would like more, not less, work that people like Adam constructed in the past years. Me and my company would like more work like the excellent sumtype inclusion in Phobos, to give you a concrete example.

But again, that's OT. I reiterate: what we can do to have a best handling of events that resulted in what we are seeing today, the fork. I've given my suggestion, we need more people like Steven and his attitude as maintainers.

> The core of the doom discourse is that somehow core team limits D, I feel instead that the community fails to be supportive when it needs to and even accept users behaving in a unprofessional way...

Maybe, but I think that the common feeling is exactly the opposite, and that's what I've observed since many, many, many years. Things are moving toward better in recent months, so it's seems to me that's the right time to tackle this specific issue, as it seems at hand.

To be clear, I don't care if at the end interpolation is merged or not, I care to see improvements in way people are managed.

> If it were for the common good it would be worth it, but I think we're learning eventually that putting up with bad behaviour is not worth it.

I totally agree, and I reiterate:  how to avoid to rouse people to that point?

/P

On Wednesday, 10 January 2024 at 15:40:55 UTC, Nick Treleaven wrote:
> On Tuesday, 9 January 2024 at 22:10:45 UTC, Lance Bachmeier wrote:
>> If you contribute this work to the fork, you'll have folks to try it out and provide feedback, and you won't have to add experimental flags to the compiler or mess with the compiler at all.
>
> My impression so far is that the openD fork may diverge too far from dmd to be able to merge changes upstream. They've already changed the layout of the repositories - combining phobos and ldc into the compiler one. Maybe my git knowledge is not perfect, but it seems to have made merging openD changes back into dmd much more awkward.

It's hard to say at this point. A fork doesn't have to diverge terribly far from upstream. This fork would be quite helpful if it provided a way to experiment with new ideas that could be merged upstream - something that doesn't happen enough now.

On Wednesday, 10 January 2024 at 17:21:26 UTC, bachmeier wrote:
> It's hard to say at this point. A fork doesn't have to diverge terribly far from upstream. This fork would be quite helpful if it provided a way to experiment with new ideas that could be merged upstream - something that doesn't happen enough now.

Like "experimental" or "nightly" edition...
But I think OpenD doesn't have it in mind by design

On Wed, Jan 10, 2024 at 05:21:26PM +0000, bachmeier via Digitalmars-d wrote:
> On Wednesday, 10 January 2024 at 15:40:55 UTC, Nick Treleaven wrote:
[...]
> > My impression so far is that the openD fork may diverge too far from dmd to be able to merge changes upstream. They've already changed the layout of the repositories - combining phobos and ldc into the compiler one.  Maybe my git knowledge is not perfect, but it seems to have made merging openD changes back into dmd much more awkward.

Adam merged the repos for ease of management.  As far as the code itself is concerned, he's generally taking the more conservative approach of not breaking things deliberately unless there's a good reason to.  Of course, this will eventually lead to irreconciliable divergence from upstream, but it won't happen overnight.  The plan is to stay close to D as much as possible.


> It's hard to say at this point. A fork doesn't have to diverge terribly far from upstream. This fork would be quite helpful if it provided a way to experiment with new ideas that could be merged upstream - something that doesn't happen enough now.

Judging from the responses to this thread, it seems clear that the current upstream team is not interested in changing their direction. Which means that merging features back from the fork is probably not going to happen, since these features generally would be those that upstream has rejected.  So I'm not holding my breath.

The best that could happen in this scenario is that upstream would borrow ideas from the fork, but would write their own implementation, possibly with changes to suit their taste.  It doesn't seem very likely that code from the fork would be adopted as-is by upstream.


T

-- 
PENTIUM = Produces Erroneous Numbers Thru Incorrect Understanding of Mathematics

On Wednesday, 10 January 2024 at 17:46:38 UTC, H. S. Teoh wrote:
> Judging from the responses to this thread, it seems clear that the current upstream team is not interested in changing their direction. Which means that merging features back from the fork is probably not going to happen, since these features generally would be those that upstream has rejected.  So I'm not holding my breath.

Maybe... But from the discussions on the forum it rather seems that the problem is not the features being rejected but the speed in which they are discussed, and sometime the seemingly reluctance of Walter to try to understand what the community thinks (like safe for extern(c) or now the interpolate strings).

Yet, taking time to accept features may be beneficial. Imagine that the first dip of Adam and Steven would be accepted, or the original DIP1036. We would never come to the DIP1036e, which I hope will be accepted. (After Attila reverse engineers the implementation...)

On 1/10/2024 3:01 AM, GrimMaple wrote:
> When you have the mentality of

Rudeness to any forum member is not acceptable here.

> Funny you say this, because I had to update the compiler recently (to work on OpenD), and it started spitting out deprecations on my other code. And it's something that I've been complaining about for years, yet here we are. Updating the compiler even one version ahead gives me deprecations.

Please post what they are and I will address them.