On Thursday, 20 February 2020 at 10:58:36 UTC, Walter Bright wrote:
> On 2/19/2020 10:34 PM, Seb wrote:
>> And I haven't even mentioned the bottleneck of any major DMD PR needing to be approved by Walter.
>
> Given the current regression list:
>
> https://issues.dlang.org/buglist.cgi?bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&list_id=230215&query_format=advanced
>
> I'm probably being too permissive. I'm usually the one who gets to fix them. I asked in this forum for some help isolating which PRs caused the regressions, to no avail.
>
> Major PRs *should* be regarded with skepticism. For example, I recently fixed a regression caused by a 2 or 3 hundred line PR, where the substance of the PR was one line and the rest of it was refactoring.
>
> Folks, with PRs, smaller, tightly focused PRs are better. Do not:
>
> 1. lump multiple issues into one PR
>
> 2. include your favorite refactorings in with it
>
> 3. refactors must not change observable behavior
>
> Do:
>
> 1. minimize the PR even if the result of the PR suggests a refactoring
>
> 2. do that refactor SEPARATELY AFTER THE PR WAS MERGED

I've fixed a regression caused by one of your PRs. It was a small change to the actual code, couldn't have been more than 10 lines, but it changed a few of the test case outputs. Funnily enough there were valid test cases with error messages that were just nuked over blindly (automatically probably). Errors happen, even for very simple things, if you don't take care it doesn't matter what the size of the PR is.

People have trouble getting one PR merged, and you want them to try and split them up and somehow have that be coordinated properly when the PR have to be merged in a certain order and across 3 different projects? Yah, no thanks.

On Thursday, 20 February 2020 at 13:11:21 UTC, Guillaume Piolat wrote:
> On Thursday, 20 February 2020 at 06:08:03 UTC, Seb wrote:
>>
>> "Funnily" we changed the defaults for dub (one can't build anything with optlink, no vibe.d, no phobos etc. anyhow) more than a year ago and people are fine with dub using LLD (like LDC) and thus being able to have more than 32k symbols in their entire program, getting a 64-bit binary by default and not being linked with an ancient, full of well-known and decade-old bugs custom-brew Digitalmars libc.
>
> Hello,
>
> Reading the discussion, it seems something undervalued is the morale of contributors.
>
> Getting and _keeping_ contributors is of paramount importance to open-source software. Some say that metric dwarf the importance of _having users_, and is the only real health metrics of a project.
>
> Please (D leadership) consider keeping contributors happy, even if that means dropping a backend or OPTLINK or both. Projects that nly person understand can be "unbabyfied" with documentation/Wiki/years of contribution, but not having the problem in the first place is much easier.

To be the devil's advocate, no one has contributed to D longer than Walter, and in the 20+ year he's been working on D, I'm sure he's seen countless contributors coming and going, many of them proposed ideas they considered improvements.

Everyone has a their own, often conflicting, vision of what is "the right way". We had many people saying "deprecate scope class" (myself included), we let it happen, and then one of the biggest commercial user steps in and said "Hey guys we're using this feature, like, a lot...". It surely makes you reflect on the silent majority. This is one example out of many where we went one way, and things didn't quite work out as expected.
As you cannot satisfy everyone, keeping people happy is not a reliable metric.

This is not to say that I think everything is going as it should. I do think that there is a lot to gain with dropping homegrown alternative to mainstream utilities (DM Make, optlink, DMD's backend...).
But we made immense progress over the years, as some very large projects have been tackled (conversion of DMD to D), and others have been approved but not yet championed (moving from Bugzilla to DMD).

Perhaps improving communication among core contributors could help with reaching agreement on such large project. From what I've seen, this is not a problem that is unique to D.

Thank you.

On Thursday, 20 February 2020 at 06:34:45 UTC, Seb wrote:

> In my opinion DMD is only the default because switching development efforts to LDC would be a rather big initial cost (time investment) to setup/change the infrastructure and no one wants to head this effort.
>
>> if the d core team is focused in that direction, most people will follow suit.
>
> I would switch in a heartbeat and I am fairly confident to estimate that the same applies to almost all remaining active contributors who haven't left yet because of frustration.


I used to think that the backend should be abandoned in favour of LLVM but no more. I think it is worth having a fast backend. I was surprised how quickly dmd can be compiled compared to LLVM.

It is excellent for a language designer to have full control over the implementation too as it helps play with ideas without having to fight with external libraries.

Regards

On 2/20/2020 12:35 PM, Dibyendu Majumdar wrote:
> I used to think that the backend should be abandoned in favour of LLVM but no more. I think it is worth having a fast backend. I was surprised how quickly dmd can be compiled compared to LLVM.
> 
> It is excellent for a language designer to have full control over the implementation too as it helps play with ideas without having to fight with external libraries.

I might add that having a fast edit-compile-debug loop is indeed transformative. Sometimes tracking down a problem may require hundreds of times through that loop.

On my dev machine, a full debug build of dmd takes 43 seconds.

An incremental build (one file change) takes 9 seconds.

(The build compiler is a Windows 32 bit dmd built with dmd.)

On Thursday, 20 February 2020 at 21:04:16 UTC, Walter Bright wrote:
> On 2/20/2020 12:35 PM, Dibyendu Majumdar wrote:
>> I used to think that the backend should be abandoned in favour of LLVM but no more. I think it is worth having a fast backend. I was surprised how quickly dmd can be compiled compared to LLVM.
>> 
>> It is excellent for a language designer to have full control over the implementation too as it helps play with ideas without having to fight with external libraries.
>
> I might add that having a fast edit-compile-debug loop is indeed transformative. Sometimes tracking down a problem may require hundreds of times through that loop.
>
> On my dev machine, a full debug build of dmd takes 43 seconds.
>
> An incremental build (one file change) takes 9 seconds.
>
> (The build compiler is a Windows 32 bit dmd built with dmd.)

43 seconds?
Are you still on an hdd?

On 2/20/2020 6:39 AM, Guillaume Piolat wrote:
> Now imagine if Linux spent all his time implementing Linux drivers instead of spending all its time reviewing. He would probably say "there is no time for review".

There are 24 members of Team DMD, which have pull privileges:

  https://github.com/orgs/dlang/teams/team-dmd/members

Team Phobos has 34 members:

  https://github.com/orgs/dlang/teams/team-phobos/members

If you feel your PRs are being ignored, make some noise to these people. It's what they're there for.

On 2/20/2020 1:07 PM, Stefan Koch wrote:
> 43 seconds?
> Are you still on an hdd?

No. But my computer is an older one.

On Thursday, 20 February 2020 at 21:10:31 UTC, Walter Bright wrote:
> On 2/20/2020 6:39 AM, Guillaume Piolat wrote:
>> Now imagine if Linux spent all his time implementing Linux drivers instead of spending all its time reviewing. He would probably say "there is no time for review".
>
> There are 24 members of Team DMD, which have pull privileges:
>
>   https://github.com/orgs/dlang/teams/team-dmd/members
>
> Team Phobos has 34 members:
>
>   https://github.com/orgs/dlang/teams/team-phobos/members
>
> If you feel your PRs are being ignored, make some noise to these people. It's what they're there for.

Both of those links show a 404 page for me. I don't think this information is visible to users who aren't part of the Github dlang organization.

On 2/20/2020 2:42 PM, Paul Backus wrote:
> Both of those links show a 404 page for me. I don't think this information is visible to users who aren't part of the Github dlang organization.

Team DMD:

	@dnadlinger
	@braddr
	@CyberShadow
	@DmitryOlshansky
	@MartinNowak
	@jacob-carlborg
	@ibuclaw
	@andralex
	@WalterBright
	@yebblies
	@schveiguy
	@rainers
	@Geod24
	@don-clugston-sociomantic
	@PetarKirov
	@wilzbach
	@atilaneves
	@AndrewEdwards
	@auto-tester	
	@thewilsonator
	@SSoulaimane
	@AndrejMitrovic
	@dlang-bot
	@RazvanN7

Team Phobos:

        burner burner
	@repeatedly	repeatedly repeatedly
	@dnadlinger	dnadlinger dnadlinger
	@braddr	braddr braddr
	@alexrp	alexrp alexrp
	@JakobOvrum	JakobOvrum JakobOvrum
	@CyberShadow	CyberShadow CyberShadow
	@kyllingstad	kyllingstad kyllingstad
	@DmitryOlshansky	DmitryOlshansky DmitryOlshansky
	@MartinNowak	MartinNowak MartinNowak Maintainer
	@ibuclaw	ibuclaw ibuclaw
	@quickfur	quickfur quickfur
	@andralex	andralex andralex
	@WalterBright	WalterBright WalterBright
	@jmdavis	jmdavis jmdavis
	@yebblies	yebblies yebblies
	@schveiguy	schveiguy schveiguy
	@JackStouffer	JackStouffer JackStouffer
	@rainers	rainers rainers
	@9il	9il 9il
	@Hackerpilot	Hackerpilot Hackerpilot
	@UplinkCoder	UplinkCoder UplinkCoder
	@PetarKirov	PetarKirov PetarKirov
	@edi33416	edi33416 edi33416
	@wilzbach	wilzbach wilzbach
	@MetaLang	MetaLang MetaLang
	@atilaneves	atilaneves atilaneves
	@AndrewEdwards	AndrewEdwards AndrewEdwards
	@auto-tester	auto-tester auto-tester
	@jercaianu	jercaianu jercaianu