• IM (16/16) Dec 28 2017 I will start:
• Daniel Kozak (5/20) Dec 29 2017 You should fill an issue on issues.dlang.org for this particular case.
• codephantom (10/11) Dec 29 2017 I will add:
• vit (37/53) Dec 29 2017 Similar problem is when some template with alias callback fail to
• JN (5/5) Dec 29 2017 AFAIK Rust doesn't have templates, but generics. Generics usually
• I Love Stuffing (6/11) Dec 29 2017 Templates are bad because they write code for you. And it's that
• Elronnd (4/6) Dec 29 2017 std.container.dlist
• rumbu (5/11) Dec 29 2017 The queue or stack usage is not obvious at all. One would expect
• Patrick Schluter (18/29) Dec 30 2017 Yes, it's the same issue in C when using complicated macros. You
• Dylan Graham (4/20) Dec 29 2017 I'd like to see proper DLL (shared library) support and DIP45
• angel (3/19) Dec 29 2017 Built-in tuples:
• maarten van damme (5/33) Dec 29 2017 I'm making a project that I hope in the future will be extendable with D
• rikki cattermole (3/9) Dec 29 2017 The starting problem is TypeInfo doesn't cross the dll/host binary
• Basile B. (9/15) Dec 29 2017 I casually encountered D issues that i qualified as "major" but
• Satoshi (15/31) Dec 29 2017 This topic was there for so many times.
• Arek (4/9) Dec 29 2017 I would like to have a complete and well-defined memory model.
• Adam D. Ruppe (3/5) Dec 29 2017 This is the only thing I greatly care about anymore. Biggest
• Walter Bright (3/9) Dec 29 2017 This is not actionable. What is actionable is filing bugzilla enhancemen...
• Adam D. Ruppe (9/11) Dec 29 2017 I've done better than that: I've written pull requests.
• Walter Bright (6/18) Dec 29 2017 That's been closed for a while now.
• Adam D. Ruppe (22/23) Dec 29 2017 Well, take your pick:
• IM (22/47) Dec 29 2017 Just curious, why Bugzilla and not something else? I can guess
• Adam D. Ruppe (4/5) Dec 29 2017 Bugzilla was the most well-known solution at the time. Keep in
• Seb (28/33) Dec 31 2017 No it wouldn't be a big pain. There are many tools for
• Meta (13/45) Dec 31 2017 I wholeheartedly agree. The customer is always right, especially
• Mengu (15/70) Dec 31 2017 there are three things that i've noticed:
• rjframe (10/14) Dec 31 2017 That's probably not the best method of effecting change.
• Pjotr Prins (25/26) Jan 01 2018 It killed off the discussion nicely, indeed.
• Patrick Schluter (2/28) Jan 02 2018 +10000
• H. S. Teoh (6/33) Jan 02 2018 +10000 * 2
• IM (13/47) Jan 03 2018 To clarify, I too like D. It is certainly very pleasant to work
• codephantom (15/27) Jan 03 2018 D is one of the most interesting and easy to use languages I've
• Mike Parker (20/22) Jan 03 2018 Several bugs get wiped in each release, as the changelogs clearly
• codephantom (3/5) Jan 03 2018 This is the mystery behind everything in the universe.
• codephantom (14/24) Jan 03 2018 I think this might also be a good project for one of Andrei's
• H. S. Teoh (34/38) Jan 03 2018 [...]
• Paolo Invernizzi (2/3) Jan 04 2018 I'm missing Kenji...
• codephantom (27/30) Jan 04 2018 I think that view really needs to be challenged.
• rjframe (14/25) Jan 04 2018 At the time of writing:
• codephantom (15/22) Jan 04 2018 Whether D is usable, reliable or whatever was not my argument.
• Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (5/6) Jan 05 2018 Most appears to be library related or improvement requests…
• Jonathan M Davis (52/86) Dec 31 2017 I honestly am unaware of any reason why using github issues would be
• rjframe (6/20) Dec 31 2017 If only one person has access to Bugzilla, we're actually at a greater
• Walter Bright (5/5) Dec 29 2017 Creating a bugzilla account takes a couple minutes. It is enough frictio...
• Muld (20/22) Dec 30 2017 Yah there are a ton of Bugzilla issues, that's the problem. More
• Iain Buclaw (27/48) Dec 30 2017 There's nothing unmanageable about the issue tracker, nor are the
• codephantom (12/22) Dec 30 2017 Is this a problem with triage?
• Iain Buclaw (11/27) Dec 30 2017 Either:
• codephantom (5/8) Dec 30 2017 "This list is too long for Bugzilla's little mind"
• Muld (4/16) Dec 31 2017 I haven't been looking recently. At least there's one vigilante
• Walter Bright (5/11) Dec 30 2017 Anyone can contribute to bugzilla with reasoned advice about what to do ...
• IM (7/20) Dec 30 2017 While we are discussing it here, could you please let me know
• Walter Bright (5/10) Dec 30 2017 Bugs are ranked by severity, but generally what gets fixed are bugs that...
• IM (15/29) Dec 31 2017 I hope that you could see that this doesn't scale very well, and
• Walter Bright (6/7) Dec 31 2017 We've tried adding process before. It does not work, for the simple reas...
• codephantom (17/24) Dec 31 2017 Well, I've spent the last few months just learning the language,
• IM (22/30) Jan 01 2018 Something should work. It just needs to be found. People are
• Muld (11/20) Dec 31 2017 I already have, and like I said there are problems with with the
• Walter Bright (4/5) Dec 31 2017 A word to the wise. Being rude will just get you ignored by most everyon...
• Binghoo Dang (17/18) Jan 05 2018 Stop making noise except one-day you make another well-known
• Meta (18/32) Dec 31 2017 This is a problem that many of us are working on fixing. The main
• Seb (11/51) Dec 31 2017 Yes, Dlang-bot was able to detect stalled issues for a while, but
• Meta (4/14) Dec 31 2017 Awesome. Thanks for all your hard work on the automation side of
• Walter Bright (3/4) Dec 29 2017 PRs to fix bugzilla issues get submitted every day. I don't see a better...
• Muld (17/27) Dec 29 2017 Bugzilla is a huge mess tbh, creating a request in bugzilla won't
• Walter Bright (5/8) Dec 29 2017 It's not a big deal to create a duplicate of existing entries. As to bug...
• Muld (10/21) Dec 30 2017 This does not mean anything, just cause fixes for Bugzilla issues
• IM (34/39) Dec 29 2017 Please allow me to give an example of how first impressions of
• Walter Bright (3/10) Dec 29 2017 I'm sorry, there is literally nothing I can do with that. To get action,...
• ag0aep6g (4/7) Dec 30 2017 As far as I'm aware, the foundation isn't too active in those areas;
• Laeeth Isharc (93/140) Jan 04 2018 Then probably you did the right thing in not suggesting they move
• Paolo Invernizzi (11/16) Jan 05 2018 +1000
• Neia Neutuladh (18/20) Dec 29 2017 Very much so.
• Walter Bright (5/8) Dec 29 2017 Diverging from the:
• Seb (5/14) Dec 29 2017 It's easy to detect whether the compiler is invoked in a TTY.
• Atila Neves (3/21) Dec 29 2017 Being in an editor does not imply being in a TTY.
• rjframe (14/25) Dec 29 2017 I think the idea of the OP is that the message should be better; not tha...
• Walter Bright (9/17) Dec 29 2017 Many compilers produce such error codes. I've considered it many times, ...
• codephantom (4/8) Dec 29 2017 No URLs! (unless they point to 'local' documentation).
• radagast (12/28) Dec 30 2017 * R-value references.

IM <3di gm.com> writes:

I will start:

    -- Better compiler errors, better compiler errors, better 
compiler errors.


I really wish that the compiler errors could receive some 
refinement. Mostly it feels like some error text just being 
thrown at me. It needs to be better formatted, more helpful, with 
suggestions about how to fix (if possible).

To illustrate my point:

- See the compile errors I've just encountered with DMD: 
https://cdn.pbrd.co/images/H0q609l.png

- Now compare that with an error produced by rustc:
https://cdn.pbrd.co/images/H0q6bLi.png


Simple things like these make a big difference. D Lang has been 
around for a long while now, and hence signs of its maturity has 
to show everywhere, especially in the compiler, as well as the 
package manager.

Daniel Kozak <kozzi11 gmail.com> writes:

You should fill an issue on issues.dlang.org for this particular case.
Compile should give you some hint, that you should use lvalue instead of
rvalue.

On Fri, Dec 29, 2017 at 8:53 AM, IM via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 I will start:

    -- Better compiler errors, better compiler errors, better compiler
 errors.


 I really wish that the compiler errors could receive some refinement.
 Mostly it feels like some error text just being thrown at me. It needs to
 be better formatted, more helpful, with suggestions about how to fix (if
 possible).

 To illustrate my point:

 - See the compile errors I've just encountered with DMD:
 https://cdn.pbrd.co/images/H0q609l.png

 - Now compare that with an error produced by rustc:
 https://cdn.pbrd.co/images/H0q6bLi.png


 Simple things like these make a big difference. D Lang has been around for
 a long while now, and hence signs of its maturity has to show everywhere,
 especially in the compiler, as well as the package manager.

codephantom <me noyb.com> writes:

On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
 I will start:

I will add:


// ----------
module test;

import std.stdio;

 safe void main()
{
     writeln("I'd like to see  safe as being the default");
}

// ------------

vit <vit vit.vit> writes:

On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
 I will start:

    -- Better compiler errors, better compiler errors, better 
 compiler errors.


 I really wish that the compiler errors could receive some 
 refinement. Mostly it feels like some error text just being 
 thrown at me. It needs to be better formatted, more helpful, 
 with suggestions about how to fix (if possible).

 To illustrate my point:

 - See the compile errors I've just encountered with DMD: 
 https://cdn.pbrd.co/images/H0q609l.png

 - Now compare that with an error produced by rustc:
 https://cdn.pbrd.co/images/H0q6bLi.png


 Simple things like these make a big difference. D Lang has been 
 around for a long while now, and hence signs of its maturity 
 has to show everywhere, especially in the compiler, as well as 
 the package manager.


Similar problem is when some template with alias callback fail to 
instantiate because callback contains error.
Example:

void foo(){
     string str = 1;

     /++ nice error message:
         Error: cannot implicitly convert expression `1` of type 
`int` to `string`

     +/


     import std.algorithm;

     [1, 2, 3].each!((x){
         string str = 1        ///same error
     });

     /++ horrible error message without root cause:
     source\app.d(660,14): Error: template app.foo.each!((x)

	{

	string str = 1;

	}

	).each cannot deduce function from argument types !()(int[]), 
candidates are:
	C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm\iteration.d(899,10):     
  app.foo.each!((x)

	{

	string str = 1;

	}

	).each(Range)(Range r) if (!isForeachIterable!Range && 
(isRangeIterable!Range || __traits(compiles, 
typeof(r.front).length)))
	C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm\iteration.d(934,10):     
  app.foo.each!((x)

	{

	string str = 1;

	}

	).each(Iterable)(auto ref Iterable r) if 
(isForeachIterable!Iterable || __traits(compiles, 
Parameters!(Parameters!(r.opApply))))

     +/
}

JN <666total wp.pl> writes:

AFAIK Rust doesn't have templates, but generics. Generics usually 
have much cleaner error messages because they are mostly used for 
generic functions and classes, meanwhile templates can do that 
too but much, much more, but when they break, you get entire 
paragraphs of template errors.

I Love Stuffing <ilovestuffing gmail.com> writes:

On Friday, 29 December 2017 at 09:46:05 UTC, JN wrote:
 AFAIK Rust doesn't have templates, but generics. Generics 
 usually have much cleaner error messages because they are 
 mostly used for generic functions and classes, meanwhile 
 templates can do that too but much, much more, but when they 
 break, you get entire paragraphs of template errors.

Templates are bad because they write code for you. And it's that 
code you don't write that could have errors. It's a double edge 
sword.

Also, for a mature D, some damn collections. Queues, Stacks, 
Deques, etc...

Elronnd <elronnd elronnd.net> writes:

On Friday, 29 December 2017 at 22:05:31 UTC, I Love Stuffing 
wrote:
 Also, for a mature D, some damn collections. Queues, Stacks, 
 Deques, etc...

std.container.dlist 
(https://dlang.org/phobos/std_container_dlist.html)?

rumbu <rumbu rumbu.ro> writes:

On Saturday, 30 December 2017 at 07:30:39 UTC, Elronnd wrote:
 On Friday, 29 December 2017 at 22:05:31 UTC, I Love Stuffing 
 wrote:
 Also, for a mature D, some damn collections. Queues, Stacks, 
 Deques, etc...

 std.container.dlist 
 (https://dlang.org/phobos/std_container_dlist.html)?

The queue or stack usage is not obvious at all. One would expect 
something like stack.push, stack.pop or queue.enque, queue.deque 
and may be a peek(). Instead one will get 33 functions that can 
be used with a doubly-linked list.

Patrick Schluter <Patrick.Schluter bbox.fr> writes:

On Friday, 29 December 2017 at 22:05:31 UTC, I Love Stuffing 
wrote:
 On Friday, 29 December 2017 at 09:46:05 UTC, JN wrote:
 AFAIK Rust doesn't have templates, but generics. Generics 
 usually have much cleaner error messages because they are 
 mostly used for generic functions and classes, meanwhile 
 templates can do that too but much, much more, but when they 
 break, you get entire paragraphs of template errors.

 Templates are bad because they write code for you. And it's 
 that code you don't write that could have errors. It's a double 
 edge sword.

 Also, for a mature D, some damn collections. Queues, Stacks, 
 Deques, etc...

Yes, it's the same issue in C when using complicated macros. You 
have to do all substitutions by hand to understand the real error 
message. D templates have more information so there's hope to get 
a better resolution of the error cause.
But, the error message thing is a double edge sword, the more 
information is given the more difficult it gets to quickly find 
what the issue is.
Again to illustrate with my C experience (sorry I'm paid for 
programming C, D is hobby that I try to sneakily introduce). The 
gcc 4 error messages were simple 1 lines errors, from gcc 5 on 
they introduced the multi-line errors with positioning like in 
that Rust example above. At the beginning I was quite happy with 
that as the error messages are so much more detailed, but now 
after some time, I find them really annoying as it is much more 
eye straining to find the real error message in between the 
positioning text.

Dylan Graham <dylan.graham2000 gmail.com> writes:

On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
 I will start:

    -- Better compiler errors, better compiler errors, better 
 compiler errors.


 I really wish that the compiler errors could receive some 
 refinement. Mostly it feels like some error text just being 
 thrown at me. It needs to be better formatted, more helpful, 
 with suggestions about how to fix (if possible).

 To illustrate my point:

 - See the compile errors I've just encountered with DMD: 
 https://cdn.pbrd.co/images/H0q609l.png

 - Now compare that with an error produced by rustc:
 https://cdn.pbrd.co/images/H0q6bLi.png


 Simple things like these make a big difference. D Lang has been 
 around for a long while now, and hence signs of its maturity 
 has to show everywhere, especially in the compiler, as well as 
 the package manager.

I'd like to see proper DLL (shared library) support and DIP45 
implemented. I'm making a project that I hope in the future will 
be extendable with D plugins.

angel <andrey.gelman gmail.com> writes:

Built-in tuples:

{val1, val2} = func();


On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
 I will start:

    -- Better compiler errors, better compiler errors, better 
 compiler errors.


 I really wish that the compiler errors could receive some 
 refinement. Mostly it feels like some error text just being 
 thrown at me. It needs to be better formatted, more helpful, 
 with suggestions about how to fix (if possible).

 To illustrate my point:

 - See the compile errors I've just encountered with DMD: 
 https://cdn.pbrd.co/images/H0q609l.png

 - Now compare that with an error produced by rustc:
 https://cdn.pbrd.co/images/H0q6bLi.png


 Simple things like these make a big difference. D Lang has been 
 around for a long while now, and hence signs of its maturity 
 has to show everywhere, especially in the compiler, as well as 
 the package manager.

maarten van damme <maartenvd1994 gmail.com> writes:

I'd like to see proper DLL (shared library) support and DIP45 implemented.

I'm making a project that I hope in the future will be extendable with D
plugins.


Out of curiousity, what's wrong with the current dll support?

2017-12-29 11:36 GMT+01:00 angel via Digitalmars-d <
digitalmars-d puremagic.com>:

 Built-in tuples:

 {val1, val2} = func();


 On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:

 I will start:

    -- Better compiler errors, better compiler errors, better compiler
 errors.


 I really wish that the compiler errors could receive some refinement.
 Mostly it feels like some error text just being thrown at me. It needs to
 be better formatted, more helpful, with suggestions about how to fix (if
 possible).

 To illustrate my point:

 - See the compile errors I've just encountered with DMD:
 https://cdn.pbrd.co/images/H0q609l.png

 - Now compare that with an error produced by rustc:
 https://cdn.pbrd.co/images/H0q6bLi.png


 Simple things like these make a big difference. D Lang has been around
 for a long while now, and hence signs of its maturity has to show
 everywhere, especially in the compiler, as well as the package manager.

rikki cattermole <rikki cattermole.co.nz> writes:

On 29/12/2017 11:03 AM, maarten van damme wrote:
  >I'd like to see proper DLL (shared library) support and DIP45 
 implemented. I'm making a project that I hope in the future will be 
 extendable with D plugins.
 
 
 Out of curiousity, what's wrong with the current dll support?

The starting problem is TypeInfo doesn't cross the dll/host binary 
boundary. Meaning no classes/exceptions.

Basile B. <b2.temp gmx.com> writes:

On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
 I will start:
 [...]
 Simple things like these make a big difference. D Lang has been 
 around for a long while now, and hence signs of its maturity 
 has to show everywhere, especially in the compiler, as well as 
 the package manager.

I casually encountered D issues that i qualified as "major" but 
with the time passing i don't really care anymore. D has probably 
reached the point where improving quality has become harder and 
harder.

Improving the quality does not scale linearly and i'd say so what 
you qualify as "Simple things like these" are harder to 
accomplish than that you think.

the devil is in the details.

Satoshi <satoshi rikarin.org> writes:

On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
 I will start:

    -- Better compiler errors, better compiler errors, better 
 compiler errors.


 I really wish that the compiler errors could receive some 
 refinement. Mostly it feels like some error text just being 
 thrown at me. It needs to be better formatted, more helpful, 
 with suggestions about how to fix (if possible).

 To illustrate my point:

 - See the compile errors I've just encountered with DMD: 
 https://cdn.pbrd.co/images/H0q609l.png

 - Now compare that with an error produced by rustc:
 https://cdn.pbrd.co/images/H0q6bLi.png


 Simple things like these make a big difference. D Lang has been 
 around for a long while now, and hence signs of its maturity 
 has to show everywhere, especially in the compiler, as well as 
 the package manager.


This topic was there for so many times.
Tuples, async/await, maybe monad (eg. int?), conditional 
dereferencing qualifier?.identifier, coalescence operator return 
x ?? 42;
better properties, default safety, explicit throw funcs, runtime 
reflection, ARC instead of GC, so support, ...

The community is quite conservative about implementing new stuff 
in D.

Look at for more info:
http://forum.dlang.org/thread/sapqaonpjseeykdczmvw forum.dlang.org?page=1
http://forum.dlang.org/thread/ot1q8b$23pt$1 digitalmars.com?page=1



BTW: I decided to make my own language rather than forcing the 
community to implement something what I would like to see in the 
lang. https://github.com/Rikarin/Rin

Arek <arychlinski gmail.com> writes:

On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
 I will start:

cut...
 Simple things like these make a big difference. D Lang has been 
 around for a long while now, and hence signs of its maturity 
 has to show everywhere, especially in the compiler, as well as 
 the package manager.

I would like to have a complete and well-defined memory model.
And its proper implementation in the compiler.

Adam D. Ruppe <destructionator gmail.com> writes:

On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
    -- Better compiler errors, better compiler errors, better 
 compiler errors.


This is the only thing I greatly care about anymore. Biggest 
problem D has in real world use.

Walter Bright <newshound2 digitalmars.com> writes:

On 12/29/2017 9:29 AM, Adam D. Ruppe wrote:
 On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
    -- Better compiler errors, better compiler errors, better compiler errors.

 
 
 This is the only thing I greatly care about anymore. Biggest problem D has in 
 real world use.

This is not actionable. What is actionable is filing bugzilla enhancement 
requests with specific examples.

Adam D. Ruppe <destructionator gmail.com> writes:

On Friday, 29 December 2017 at 21:30:35 UTC, Walter Bright wrote:
 This is not actionable. What is actionable is filing bugzilla 
 enhancement requests with specific examples.

I've done better than that: I've written pull requests.

https://github.com/dlang/dmd/pull/6806

There's also existing bugzilla entries such as 
https://issues.dlang.org/show_bug.cgi?id=7841


These things come up almost every day in user support requests 
(learn forum, irc, or stack overflow). You want my advice for 
what to fix on D? Just follow those places and focus on stuff 
people ask for help on.

Walter Bright <newshound2 digitalmars.com> writes:

On 12/29/2017 2:31 PM, Adam D. Ruppe wrote:
 On Friday, 29 December 2017 at 21:30:35 UTC, Walter Bright wrote:
 This is not actionable. What is actionable is filing bugzilla enhancement 
 requests with specific examples.

 
 I've done better than that: I've written pull requests.
 
 https://github.com/dlang/dmd/pull/6806

Thank you!


 There's also existing bugzilla entries such as 
 https://issues.dlang.org/show_bug.cgi?id=7841

That's been closed for a while now.


 These things come up almost every day in user support requests (learn forum, 
 irc, or stack overflow). You want my advice for what to fix on D? Just follow 
 those places and focus on stuff people ask for help on.

As a matter of pragmatism and time management, I give priority to helping
people 
who have expended the effort to document a problem and post it on bugzilla. 
There's enough there to fill all the time of many people.

Adam D. Ruppe <destructionator gmail.com> writes:

On Friday, 29 December 2017 at 23:24:45 UTC, Walter Bright wrote:
 That's been closed for a while now.

Well, take your pick:

https://issues.dlang.org/show_bug.cgi?id=12694
https://issues.dlang.org/show_bug.cgi?id=13340
https://issues.dlang.org/show_bug.cgi?id=16059

You always tell people to post to bugzilla, but many of these 
things have been posted over and over again. Bugzilla search is 
terrible, so it is frequently hard to find, but there are many 
examples there.

The benefit though of watching support requests is you see what 
people actually deal with day-to-day, and error messages, 
especially multiple overload matches of functions and templates 
and no template matches ones come up all the time. ALL THE TIME. 
 From new users and experienced users alike. Most won't put it in 
bugzilla though: they just see it as their own personal failure 
instead of a technical problem we can fix.

But any repeated support request should be seen as a user 
experience problem that we try to fix. This is where we'd get the 
most productivity - taking little bumps out of the road. D has no 
roadblocks; we can get a lot of stuff done with it exactly the 
way it is, but if you watch users actually try to use it, you'll 
see the road isn't as smooth as it could and should be.

IM <3di gm.com> writes:

On Saturday, 30 December 2017 at 01:40:39 UTC, Adam D. Ruppe 
wrote:
 On Friday, 29 December 2017 at 23:24:45 UTC, Walter Bright 
 wrote:
 That's been closed for a while now.

 Well, take your pick:

 https://issues.dlang.org/show_bug.cgi?id=12694
 https://issues.dlang.org/show_bug.cgi?id=13340
 https://issues.dlang.org/show_bug.cgi?id=16059

 You always tell people to post to bugzilla, but many of these 
 things have been posted over and over again. Bugzilla search is 
 terrible, so it is frequently hard to find, but there are many 
 examples there.

 The benefit though of watching support requests is you see what 
 people actually deal with day-to-day, and error messages, 
 especially multiple overload matches of functions and templates 
 and no template matches ones come up all the time. ALL THE 
 TIME. From new users and experienced users alike. Most won't 
 put it in bugzilla though: they just see it as their own 
 personal failure instead of a technical problem we can fix.

 But any repeated support request should be seen as a user 
 experience problem that we try to fix. This is where we'd get 
 the most productivity - taking little bumps out of the road. D 
 has no roadblocks; we can get a lot of stuff done with it 
 exactly the way it is, but if you watch users actually try to 
 use it, you'll see the road isn't as smooth as it could and 
 should be.

Just curious, why Bugzilla and not something else? I can guess 
the following:
- A centralized place for all dmd, druntime, and phobos was 
needed.
- GitHub issues are probably more limited in features and 
functionality than Bugzilla.

But think about it. Filing a bug on Bugzilla is not 
friction-free. One has to create an account, if s/he has one 
already, good luck remembering the username and password for 
something you rarely use, so spend sometime trying to remember 
and when you fail, spend time resetting your account or creating 
a new one. Finally file a bug and pray that someone will actually 
notice it and triage it to the appropriate owner! Not to mention 
that Bugzilla's UI is not pleasant.

For GitHub issues, most probably you already have an account 
there that you use often. Issues are close to where the code is. 
It's easy to see potential owners from the code's blame or git 
log. .. etc.

For better community participation, friction needs to be 
minimized as much as possible.

Adam D. Ruppe <destructionator gmail.com> writes:

On Saturday, 30 December 2017 at 02:37:24 UTC, IM wrote:
 Just curious, why Bugzilla and not something else?

Bugzilla was the most well-known solution at the time. Keep in 
mind the D bugzilla has been around since 2006. As far as I 
understand it, migration at this point is deemed a big pain.

Seb <seb wilzba.ch> writes:

On Saturday, 30 December 2017 at 02:50:48 UTC, Adam D. Ruppe 
wrote:
 On Saturday, 30 December 2017 at 02:37:24 UTC, IM wrote:
 Just curious, why Bugzilla and not something else?

 Bugzilla was the most well-known solution at the time. Keep in 
 mind the D bugzilla has been around since 2006. As far as I 
 understand it, migration at this point is deemed a big pain.

No it wouldn't be a big pain. There are many tools for 
automatically migrating issues from Bugzilla. The only thing 
depending on Bugzilla is the changelog generator, but it's API 
calls to Bugzilla can be replaced with GitHub API calls within an 
hour.
So the entire migration could be easily done in a lot less than a 
day.

The only reason we still use Bugzilla is that the core people are 
used to it. Here are a couple of the common arguments:

1) Bugzilla is our, we don't want to depend on GitHub

The D ecosystem already heavily depends on GitHub. Exporting the 
issues from GitHub would be easy. Besides there is only one 
person with access to the Bugzilla server.

2) GitHub only has per registry issues

Bugzilla uses components too, they don't support global issues 
either. Besides if that's required one could easily create a meta 
repository for such global tasks.

3) Bugzilla's issue tracker is more sophisticated

Sure, but does this help when you loose out on many contributors?
GitHub even has build tools and sites that let anyone discover 
"easy" issues if they are labeled accordingly. It's free 
marketing.

FYI I asked the same question 1 1/2 years ago: 
https://forum.dlang.org/post/ezldcjzpmsnxvvncncsi forum.dlang.org

Since then, for example, GitHub got voting for issues, but 
Bugzilla lost it.

Meta <jared771 gmail.com> writes:

On Sunday, 31 December 2017 at 11:18:26 UTC, Seb wrote:
 On Saturday, 30 December 2017 at 02:50:48 UTC, Adam D. Ruppe 
 wrote:
 Bugzilla was the most well-known solution at the time. Keep in 
 mind the D bugzilla has been around since 2006. As far as I 
 understand it, migration at this point is deemed a big pain.

 No it wouldn't be a big pain. There are many tools for 
 automatically migrating issues from Bugzilla. The only thing 
 depending on Bugzilla is the changelog generator, but it's API 
 calls to Bugzilla can be replaced with GitHub API calls within 
 an hour.
 So the entire migration could be easily done in a lot less than 
 a day.

 The only reason we still use Bugzilla is that the core people 
 are used to it. Here are a couple of the common arguments:

 1) Bugzilla is our, we don't want to depend on GitHub

 The D ecosystem already heavily depends on GitHub. Exporting 
 the issues from GitHub would be easy. Besides there is only one 
 person with access to the Bugzilla server.

 2) GitHub only has per registry issues

 Bugzilla uses components too, they don't support global issues 
 either. Besides if that's required one could easily create a 
 meta repository for such global tasks.

 3) Bugzilla's issue tracker is more sophisticated

 Sure, but does this help when you loose out on many 
 contributors?
 GitHub even has build tools and sites that let anyone discover 
 "easy" issues if they are labeled accordingly. It's free 
 marketing.

 FYI I asked the same question 1 1/2 years ago: 
 https://forum.dlang.org/post/ezldcjzpmsnxvvncncsi forum.dlang.org

 Since then, for example, GitHub got voting for issues, but 
 Bugzilla lost it.

I wholeheartedly agree. The customer is always right, especially 
when you're trying to get them to donate their time to an open 
source project. It's more essential than ever that we lower 
barriers to participation; if Github issues is the hip new thing 
all the kids like, then we need to switch to that. We shouldn't 
be constantly switching to the shiniest new toy, but nor should 
we stubbornly stick to a piece of software that was built (and it 
looks it) in '90s.

Or at least we should if we're trying to attract the kind of 
people for whom not using Github is a deal breaker. Older 
C++/Java programmers likely don't care, but younger 
Python/Ruby/JS users will.

Mengu <mengukagan gmail.com> writes:

On Sunday, 31 December 2017 at 19:49:07 UTC, Meta wrote:
 On Sunday, 31 December 2017 at 11:18:26 UTC, Seb wrote:
 On Saturday, 30 December 2017 at 02:50:48 UTC, Adam D. Ruppe 
 wrote:
 Bugzilla was the most well-known solution at the time. Keep 
 in mind the D bugzilla has been around since 2006. As far as 
 I understand it, migration at this point is deemed a big pain.

 No it wouldn't be a big pain. There are many tools for 
 automatically migrating issues from Bugzilla. The only thing 
 depending on Bugzilla is the changelog generator, but it's API 
 calls to Bugzilla can be replaced with GitHub API calls within 
 an hour.
 So the entire migration could be easily done in a lot less 
 than a day.

 The only reason we still use Bugzilla is that the core people 
 are used to it. Here are a couple of the common arguments:

 1) Bugzilla is our, we don't want to depend on GitHub

 The D ecosystem already heavily depends on GitHub. Exporting 
 the issues from GitHub would be easy. Besides there is only 
 one person with access to the Bugzilla server.

 2) GitHub only has per registry issues

 Bugzilla uses components too, they don't support global issues 
 either. Besides if that's required one could easily create a 
 meta repository for such global tasks.

 3) Bugzilla's issue tracker is more sophisticated

 Sure, but does this help when you loose out on many 
 contributors?
 GitHub even has build tools and sites that let anyone discover 
 "easy" issues if they are labeled accordingly. It's free 
 marketing.

 FYI I asked the same question 1 1/2 years ago: 
 https://forum.dlang.org/post/ezldcjzpmsnxvvncncsi forum.dlang.org

 Since then, for example, GitHub got voting for issues, but 
 Bugzilla lost it.

 I wholeheartedly agree. The customer is always right, 
 especially when you're trying to get them to donate their time 
 to an open source project. It's more essential than ever that 
 we lower barriers to participation; if Github issues is the hip 
 new thing all the kids like, then we need to switch to that. We 
 shouldn't be constantly switching to the shiniest new toy, but 
 nor should we stubbornly stick to a piece of software that was 
 built (and it looks it) in '90s.

 Or at least we should if we're trying to attract the kind of 
 people for whom not using Github is a deal breaker. Older 
 C++/Java programmers likely don't care, but younger 
 Python/Ruby/JS users will.

there are three things that i've noticed:

- in this thread, there is not a single positive post by walter. 
none. nada. zilch. it'd have been much better if he just did not 
post anything.

- d leadership is dusty and so are their tools. we are no js 
community and hope we never become anything like them but 
bugzilla is a hundred years old. i am on github, i am on this ml 
and i also need a bugzilla account? what else do i need to be a 
part of this community? why can't you provide me a seamless 
travel in between? have a forum software, allow me to sign in via 
github and i am a member of the community. but no, they love 
their ugly bugzilla, they love their mailing list.

- has anyone realized we do not attract anyone who has just 
started to learn programming? what are we going to do about it?

rjframe <dlang ryanjframe.com> writes:

On Sun, 31 Dec 2017 23:50:04 +0000, Mengu wrote:

 - d leadership is dusty and so are their tools. we are no js community
 and hope we never become anything like them but bugzilla is a hundred
 years old. i am on github, i am on this ml and i also need a bugzilla
 account?

That's probably not the best method of effecting change.

With the exception of the "Add me to CC list" interface (which is 
inexcusable) I like Bugzilla. It might be possible to clean things up a 
bit to better utilize it, but it offers more flexibility than Github's 
simple issue tracker does (there's a reason Atlassian is able to sell Jira 
to Bitbucket users even with a tracker integrated into Bitbucket).

Druntime and Phobos are so closely integrated that being able to search 
for issues on both of them at once can be helpful; I would sometimes 
require two separate searches if they were on Github.

Pjotr Prins <pjotr.public12 thebird.nl> writes:

On Monday, 1 January 2018 at 02:02:03 UTC, rjframe wrote:
 That's probably not the best method of effecting change.

It killed off the discussion nicely, indeed.

I am just going to share my thoughts a little. Github, in my 
opinion, is hype and even though I depend on it today, I am 
trying to decrease that dependency. We should build a world that 
is not dependent on single companies. I am not downplaying what 
github has done for us (I am one of the early users) - but they 
have just become a little too important for free software to be 
comfortable. The github issue tracker is wanting anyway.

D is a great language. I just spent 6 months in C++ and the last 
month worked on a D multi-threaded project again. I'll blog about 
this soon, but the short of it is that I am very grateful to 
Walter, Andrei, Kai, Ian, Johan and others for creating a 
language that fits our needs so well! D software is doing 
critical work around the world every second. D is probably not a 
language for the hype community - let them have Go and Rust. I 
honestly don't care. And D should not care. Great programmers 
gyrate to powerful languages and toolboxes. I love I can read the 
source code of Phobos and understand it. I love I get low level 
access to stack variables. I love I can manipulate the heap in 
any way I want. I love we can target GPU and KNL. I love we have 
Maybe even though it is called Nullable...

A great programmer can handle D fine. As it is. Let's not try to 
be the next hype. Let's keep writing great software.

Pj.

Patrick Schluter <Patrick.Schluter bbox.fr> writes:

On Monday, 1 January 2018 at 18:32:37 UTC, Pjotr Prins wrote:
 On Monday, 1 January 2018 at 02:02:03 UTC, rjframe wrote:
 That's probably not the best method of effecting change.

 It killed off the discussion nicely, indeed.

 I am just going to share my thoughts a little. Github, in my 
 opinion, is hype and even though I depend on it today, I am 
 trying to decrease that dependency. We should build a world 
 that is not dependent on single companies. I am not downplaying 
 what github has done for us (I am one of the early users) - but 
 they have just become a little too important for free software 
 to be comfortable. The github issue tracker is wanting anyway.

 D is a great language. I just spent 6 months in C++ and the 
 last month worked on a D multi-threaded project again. I'll 
 blog about this soon, but the short of it is that I am very 
 grateful to Walter, Andrei, Kai, Ian, Johan and others for 
 creating a language that fits our needs so well! D software is 
 doing critical work around the world every second. D is 
 probably not a language for the hype community - let them have 
 Go and Rust. I honestly don't care. And D should not care. 
 Great programmers gyrate to powerful languages and toolboxes. I 
 love I can read the source code of Phobos and understand it. I 
 love I get low level access to stack variables. I love I can 
 manipulate the heap in any way I want. I love we can target GPU 
 and KNL. I love we have Maybe even though it is called 
 Nullable...

 A great programmer can handle D fine. As it is. Let's not try 
 to be the next hype. Let's keep writing great software.

+10000

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Tue, Jan 02, 2018 at 09:57:08AM +0000, Patrick Schluter via Digitalmars-d
wrote:
 On Monday, 1 January 2018 at 18:32:37 UTC, Pjotr Prins wrote:

[...]
 I am just going to share my thoughts a little. Github, in my
 opinion, is hype and even though I depend on it today, I am trying
 to decrease that dependency. We should build a world that is not
 dependent on single companies. I am not downplaying what github has
 done for us (I am one of the early users) - but they have just
 become a little too important for free software to be comfortable.
 The github issue tracker is wanting anyway.
 
 D is a great language. I just spent 6 months in C++ and the last
 month worked on a D multi-threaded project again. I'll blog about
 this soon, but the short of it is that I am very grateful to Walter,
 Andrei, Kai, Ian, Johan and others for creating a language that fits
 our needs so well! D software is doing critical work around the
 world every second. D is probably not a language for the hype
 community - let them have Go and Rust. I honestly don't care. And D
 should not care. Great programmers gyrate to powerful languages and
 toolboxes. I love I can read the source code of Phobos and
 understand it. I love I get low level access to stack variables. I
 love I can manipulate the heap in any way I want. I love we can
 target GPU and KNL. I love we have Maybe even though it is called
 Nullable...
 
 A great programmer can handle D fine. As it is. Let's not try to be
 the next hype. Let's keep writing great software.
 

 +10000

+10000 * 2


T

-- 
It is not the employer who pays the wages. Employers only handle the money. It
is the customer who pays the wages. -- Henry Ford

IM <3di gm.com> writes:

On Tuesday, 2 January 2018 at 16:32:50 UTC, H. S. Teoh wrote:
 On Tue, Jan 02, 2018 at 09:57:08AM +0000, Patrick Schluter via 
 Digitalmars-d wrote:
 On Monday, 1 January 2018 at 18:32:37 UTC, Pjotr Prins wrote:

 [...]
 I am just going to share my thoughts a little. Github, in my 
 opinion, is hype and even though I depend on it today, I am 
 trying to decrease that dependency. We should build a world 
 that is not dependent on single companies. I am not 
 downplaying what github has done for us (I am one of the 
 early users) - but they have just become a little too 
 important for free software to be comfortable. The github 
 issue tracker is wanting anyway.
 
 D is a great language. I just spent 6 months in C++ and the 
 last month worked on a D multi-threaded project again. I'll 
 blog about this soon, but the short of it is that I am very 
 grateful to Walter, Andrei, Kai, Ian, Johan and others for 
 creating a language that fits our needs so well! D software 
 is doing critical work around the world every second. D is 
 probably not a language for the hype community - let them 
 have Go and Rust. I honestly don't care. And D should not 
 care. Great programmers gyrate to powerful languages and 
 toolboxes. I love I can read the source code of Phobos and 
 understand it. I love I get low level access to stack 
 variables. I love I can manipulate the heap in any way I 
 want. I love we can target GPU and KNL. I love we have Maybe 
 even though it is called Nullable...
 
 A great programmer can handle D fine. As it is. Let's not 
 try to be the next hype. Let's keep writing great software.
 

 +10000

 +10000 * 2


 T

To clarify, I too like D. It is certainly very pleasant to work 
with. This post wasn't about GitHub issues vs Bugzilla. That was 
a get-off-at-a-tangent topic. This post is about what's needed 
for a more mature D; mature enough for extremely big companies to 
build bigger and more critical parts of their tech stacks in D 
(this *is* a huge investment)! The goal is never about making D a 
hype language.

I agree, a great programmer can handle anything, not just D as it 
is, but that's never an excuse to be complacent, it's never an 
excuse not aim for a higher quality in the D compiler and the 
infrastructure. Hope you understand.

Thanks.

codephantom <me noyb.com> writes:

On Thursday, 4 January 2018 at 05:28:40 UTC, IM wrote:
 To clarify, I too like D. It is certainly very pleasant to work 
 with. This post wasn't about GitHub issues vs Bugzilla. That 
 was a get-off-at-a-tangent topic. This post is about what's 
 needed for a more mature D; mature enough for extremely big 
 companies to build bigger and more critical parts of their tech 
 stacks in D (this *is* a huge investment)! The goal is never 
 about making D a hype language.

 I agree, a great programmer can handle anything, not just D as 
 it is, but that's never an excuse to be complacent, it's never 
 an excuse not aim for a higher quality in the D compiler and 
 the infrastructure. Hope you understand.

 Thanks.

D is one of the most interesting and easy to use languages I've 
seen in a very long time, and I really enjoy 'playing' with it.

However...what D needs, IMHO, is a strategy to better handle 
defects - as opposed to wishfully hoping that something will 
arise out of the chaos of bugzilla.

This is not my area of experise, but, if I were a manager 
evaluating the merits of D for use in a corporate software 
project, and then I went off to bugzilla and looked at the items 
for D.. I'd pause and think.....wtf is going on here.

I don't know how other open source projects manage this, or how 
other mainstream languages manage this, but I would assume there 
are 'best practices' out there...somewhere.

I doubt very much whether just allowing stuff to pile up in some 
bugzilla repository, is a best practice.

Mike Parker <aldacron gmail.com> writes:

On Thursday, 4 January 2018 at 06:16:45 UTC, codephantom wrote:

 I doubt very much whether just allowing stuff to pile up in 
 some bugzilla repository, is a best practice.

Several bugs get wiped in each release, as the changelogs clearly 
show. It's not as if they're being ignored.

If you know how to get a bunch of volunteers with such varied 
interests to work in a concerted direction, please do tell. And 
I'm not being facetious here. There have been attempts in the 
past to bring some sort of order to the chaos so that the 
perception matches the reality, but it's not something that has 
yet proven sustainable. As a result, bugs that no one steps up to 
fix get left in bugzilla for ages.

I have an idea I'm working on to potentially help get older bugs 
squashed and older PRs merged. I need to hash out the details 
before getting it going, but I'll blog about when (and if) it 
comes to fruition. There are no guarantees it will be effective, 
but it's worth a shot.

In the meantime, you could help reduce the pile by picking a bug 
to fix today. Multiple people, particularly those concerned about 
the number of old issues still open, who donate one or two days a 
month to fixing old bugs could go along way. The same goes for 
reviewing PRs.

codephantom <me noyb.com> writes:

On Thursday, 4 January 2018 at 06:39:24 UTC, Mike Parker wrote:
 If you know how to get a bunch of volunteers with such varied 
 interests to work in a concerted direction, please do tell.

This is the mystery behind everything in the universe.

Why haven't you solved it yet?

codephantom <me noyb.com> writes:

On Thursday, 4 January 2018 at 06:39:24 UTC, Mike Parker wrote:
 I have an idea I'm working on to potentially help get older 
 bugs squashed and older PRs merged. I need to hash out the 
 details before getting it going, but I'll blog about when (and 
 if) it comes to fruition. There are no guarantees it will be 
 effective, but it's worth a shot.

I think this might also be a good project for one of Andrei's 
students ;-)

i.e a detailed analysis of D's bugzilla repository.

Present the findings and recommendations.


 In the meantime, you could help reduce the pile by picking a 
 bug to fix today. Multiple people, particularly those concerned 
 about the number of old issues still open, who donate one or 
 two days a month to fixing old bugs could go along way. The 
 same goes for reviewing PRs.

I'm too much of 'big picture' person to get into such details ;-)

Fortunately, not all are like me ;-)

The problem, I suspect, is more to do with people wanting to 
contribute to things that matter most, and, that their 
contribution will be considered in a timely manner, by people 
with suitable expertise. If such a process exists, I am not aware 
of it.

I don't think just saying to people, 'go and find some bug that 
interests you' is sufficient to get people motivated, IMHO.

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Thu, Jan 04, 2018 at 06:39:24AM +0000, Mike Parker via Digitalmars-d wrote:
[...]
 In the meantime, you could help reduce the pile by picking a bug to fix
 today. Multiple people, particularly those concerned about the number of old
 issues still open, who donate one or two days a month to fixing old bugs
 could go along way. The same goes for reviewing PRs.

[...]

Back when I had more free time, I used to trawl bugzilla for
low-numbered bugs to find low-hanging fruit to fix. It's not hard to
setup various prebaked custom queries that allow me to, for example,
find all bugs 1 month / 2 months / 1 year / 2-5 years old with just one
mouse click. Bugzilla is actually highly configurable and can be made to
do quite useful things, as long as people get past the fallacious
preconception that no eye candy == lousy. Over time, at least while I
was active, I have noticed that the number of trivial bugs has shrunk
significantly, and most of the lingering old issues are the ones that
are actually very difficult to fix. So the talk about stuff rotting in
bugzilla and forgotten is mostly unfounded speculation of people who
haven't even bothered to look deeper than the superficial appeatance,
rather than a reflection of reality.

Nowadays I've less time to trawl through bugzilla but every now and then
an issue comes up that can be fixed in the few spare minutes that I
have, and I still try to contribute when I can.  And I've noticed that
the number of bugs fixed per release seems to have increased, so
progress *is* being made in this area. What's lacking right now is more
people to direct more energy to fixing bugs and reviewing PRs rather
than wasting that energy complaining in the forums. For the sheer amount
of energy spent arguing on the forum, so many more bugs could have been
fixed, and so many more PRs reviewed. We don't even require you to have
commit access in order to be able to give useful feedback to a PR. I
don't know how much lower the barrier can get. Heck, *I* got commit
access because I was actively submitting and reviewing Phobos PRs as a
non-committer. It all comes down to who's doing the actual work vs.
who's just telling others what they think they should be doing, which
rarely, if ever, works.


T

-- 
Don't get stuck in a closet---wear yourself out.

Paolo Invernizzi <paolo.invernizzi gmail.com> writes:

On Thursday, 4 January 2018 at 07:47:41 UTC, H. S. Teoh wrote:
 [...]

I'm missing Kenji...

codephantom <me noyb.com> writes:

On Thursday, 4 January 2018 at 07:47:41 UTC, H. S. Teoh wrote:
 It all comes down to who's doing the actual work vs. who's just 
 telling others what they think they should be doing, which 
 rarely, if ever, works.

I think that view really needs to be challenged.

Those who might be willing to contribute are probably not sitting 
around waiting for someone to tell them what to do. On the other 
hand, there may be legitmate reasons why they are not just 
getting involved and doing things.

I suspect, and I could be wrong, that a lack of clear process 
could be a matter of concern. I also suspect, and I could be 
wrong, that working out where best to exert their effort is not 
as simple as just finding something that interest them.

I also expect, that not everyone using D, or using these forums, 
need to be, or are equipped to be, contributors to resolving D's 
bugs. Such people should still feel free to express their 
concerns, without being told that they should go and do something.

Software quality is more important than ever, as it can impact us 
in dramatic ways these days. D needs to have quality assurance 
process in place to ensure that D's repository of bugs are 
appropriately being assessed, categorised, prioritised, and 
actioned - and this needs to evident to all. Then and only then, 
wil willing contributors be better positioned to make decisions 
about where to exert their effort.

I see this a problem for the D Foundation to address, and not 
something left up to the randomness of the open source 
development model.

btw. (although I don't see this as 'the' solution)... I do like 
this idea of labeling stuff more clearly.. 
http://issuehub.io/label-guide

rjframe <dlang ryanjframe.com> writes:

On Thu, 04 Jan 2018 06:16:45 +0000, codephantom wrote:

 This is not my area of experise, but, if I were a manager evaluating the
 merits of D for use in a corporate software project, and then I went off
 to bugzilla and looked at the items for D.. I'd pause and think.....wtf
 is going on here.
 
 I don't know how other open source projects manage this, or how other
 mainstream languages manage this, but I would assume there are 'best
 practices' out there...somewhere.
 
 I doubt very much whether just allowing stuff to pile up in some
 bugzilla repository, is a best practice.

At the time of writing:

Ansible has 3391 open bugs[1] (and ~master is often used in production).
Python has more than 6000, 2000+ with patches[2].
GCC (C and C++ components only) has 3119[3].

Bugs are part of software. That's just life. It doesn't mean the software 
is unreliable/unusable, just that it can be better.



[1]: https://github.com/ansible/ansible/issues
[2]: https://bugs.python.org/issue? template=stats
[3]: https://gcc.gnu.org/bugzilla/report.cgi?
x_axis_field=&y_axis_field=bug_status&z_axis_field=&no_redirect=1&query_format=report-
table&short_desc_type=allwordssubstr&short_desc=&product=gcc&component=c&component=c
%2B%
2B&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&cf_gcchost_type=allwordssubstr&cf_gcchost=&cf_gcctarget_type=allwordssubstr&cf_gcctarget=&cf_gccbuild_type=allwordssubstr&cf_gccbuild=&bug_id=&bug_id_type=anyexact&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&j_top=AND&f1=noop&o1=noop&v1=&format=table&action=wrap

codephantom <me noyb.com> writes:

On Thursday, 4 January 2018 at 12:11:36 UTC, rjframe wrote:
 At the time of writing:

 Ansible has 3391 open bugs[1] (and ~master is often used in 
 production).
 Python has more than 6000, 2000+ with patches[2].
 GCC (C and C++ components only) has 3119[3].

 Bugs are part of software. That's just life. It doesn't mean 
 the software is unreliable/unusable, just that it can be better.

Whether D is usable, reliable or whatever was not my argument.

My argument is more broader, and is about how an opensource 
project, like D for example, looks out for the interests of its 
users. i.e quality assurance.

1000's of bugs suggest to me, a lack of QA.

A lack of QA suggests to me, a lack of concern for the interests 
of users.

There are numerous research papers in this area, some of which I 
am in the process of reading, to gain a better understanding of 
QA in open source projects - and apparently it's a real issue of 
concern to those researching this topic.

Anyway, as I go through these research papers, I suspect that it 
is unlikely they will conclude that bugs are just a part of 
software, and that's just life.. and least.. I hope not.

Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:

On Thursday, 4 January 2018 at 12:11:36 UTC, rjframe wrote:
 Python has more than 6000, 2000+ with patches[2].

Most appears to be library related or improvement requests…

I don't think numbers is the right metric.

Tools with as many users as Python will get a lot of issues 
reported irrespective of severity or frequency.

Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:

On Sunday, December 31, 2017 11:18:26 Seb via Digitalmars-d wrote:
 On Saturday, 30 December 2017 at 02:50:48 UTC, Adam D. Ruppe

 wrote:
 On Saturday, 30 December 2017 at 02:37:24 UTC, IM wrote:
 Just curious, why Bugzilla and not something else?

 Bugzilla was the most well-known solution at the time. Keep in
 mind the D bugzilla has been around since 2006. As far as I
 understand it, migration at this point is deemed a big pain.

 No it wouldn't be a big pain. There are many tools for
 automatically migrating issues from Bugzilla. The only thing
 depending on Bugzilla is the changelog generator, but it's API
 calls to Bugzilla can be replaced with GitHub API calls within an
 hour.
 So the entire migration could be easily done in a lot less than a
 day.

 The only reason we still use Bugzilla is that the core people are
 used to it. Here are a couple of the common arguments:

I honestly am unaware of any reason why using github issues would be
superior to bugzilla except that some folks expect projects on github to use
github issues for bug reports. And plenty of projects on github don't use
github issues.

If we were starting from scratch, then maybe it would make sense to use
github issues instead of our own bugzilla, but given that we already have
bugzilla, it works just fine, and github issues really don't seem to offer
anything significant that would make them superior to using bugzilla, I
really don't see any reason to switch.

 1) Bugzilla is our, we don't want to depend on GitHub

 The D ecosystem already heavily depends on GitHub. Exporting the
 issues from GitHub would be easy. Besides there is only one
 person with access to the Bugzilla server.

Yes, it would be a pain to switch away from github at this point, but if
github went down permanently tomorrow, it would just be an annoying
roadblock. We almost certainly wouldn't lose any code (at most, a few
commits, if no one pulled recently enough), and we wouldn't lose any bug
reports. We'd have to go to the trouble of setting up our own gitlab or
switching to bitbucket or something like that and pointing all of the
automated stuff to the new place, and it would be a royal pain, but we
wouldn't lose any information. If all of the issues were on github, and
github went away, we'd lose them.

Sure, github is unlikely to go away, but I see no reason to tie ourselves to
it thoroughly enough that we're going to lose data if they go away -
especially since I don't actually see any benefit in switching to github
issues.

 2) GitHub only has per registry issues

 Bugzilla uses components too, they don't support global issues
 either. Besides if that's required one could easily create a meta
 repository for such global tasks.

Well, it wouldn't be the end of the world if the issues were separated by
repos, but having them in a single place where they can be searched together
is beneficial, and it makes it easier to switch an issue between components
when it turns out that it was assigned to the wrong component. Certainly,
switching to github would be negative in this regard, even if it wouldn't be
a deal breaker.

 3) Bugzilla's issue tracker is more sophisticated

 Sure, but does this help when you loose out on many contributors?
 GitHub even has build tools and sites that let anyone discover
 "easy" issues if they are labeled accordingly. It's free
 marketing.

I seriously doubt that we've lost many (if any) contributors because we
don't use github issues, and plenty of other projects use github without
using it as their issue tracker.

 FYI I asked the same question 1 1/2 years ago:
 https://forum.dlang.org/post/ezldcjzpmsnxvvncncsi forum.dlang.org

 Since then, for example, GitHub got voting for issues, but
 Bugzilla lost it.

To be honest, no one seems to pay attention to voting on issues. Having a
voting system is theoretically beneficial, but in practice, it doesn't seem
to have generally had much effect on what gets fixed (not for us anyway).
Almost inevitably, the stuff that actually gets many votes is the hard stuff
that is likely to be sitting around whether folks vote on it or not. Plenty
of those issues really should be fixed sooner, but having a lot of votes on

everyone agreeing that it needed to be fixed, because it a was a hard
problem, and no one stepped up to the plate to take care of it. The fact
that it had a bunch of votes really didn't matter.

In any case, I have yet to see much on argument for why we would even want
to switch to github issues. It just seems like some folks think that for
some reason, the fact that we have our code up on github means that we
should have our issue tracker there too and that it's weird that we don't.
Personally, I don't see any reason to go to the trouble of searching and
invalidating years worth of links just because using github issues seems to
be the hip thing to do. It needs to provide serious value over using our own
bugzilla, and I am unaware of anything that it does that is significantly
better than using bugzilla.

- Jonathan M Davis

rjframe <dlang ryanjframe.com> writes:

On Sun, 31 Dec 2017 17:19:22 -0700, Jonathan M Davis wrote:

 Yes, it would be a pain to switch away from github at this point, but if
 github went down permanently tomorrow, it would just be an annoying
 roadblock. We almost certainly wouldn't lose any code (at most, a few
 commits, if no one pulled recently enough), and we wouldn't lose any bug
 reports. We'd have to go to the trouble of setting up our own gitlab or
 switching to bitbucket or something like that and pointing all of the
 automated stuff to the new place, and it would be a royal pain, but we
 wouldn't lose any information. If all of the issues were on github, and
 github went away, we'd lose them.
 
 Sure, github is unlikely to go away, but I see no reason to tie
 ourselves to it thoroughly enough that we're going to lose data if they
 go away - especially since I don't actually see any benefit in switching
 to github issues.

If only one person has access to Bugzilla, we're actually at a greater 
risk now than if we used Github for issues. If we don't have regular 
backups to a location accessible to multiple members of the core team, we 
shouldn't consider Bugzilla to be a reliable data repository.


--Ryan

Walter Bright <newshound2 digitalmars.com> writes:

Creating a bugzilla account takes a couple minutes. It is enough friction to 
serve as a reasonable filter against spammers and junk postings.

It's not like we have a shortage of bugzilla issues and are wondering what to
do 
next.

It's working well enough for those who care enough to make an effort.

Muld <2 2.2> writes:

On Saturday, 30 December 2017 at 06:55:13 UTC, Walter Bright 
wrote:
 It's not like we have a shortage of bugzilla issues and are 
 wondering what to do next.

Yah there are a ton of Bugzilla issues, that's the problem. More 
than half of them aren't "actionable" as you put it.

Here's the problem, look at something like Rust:

Pull requests? 95 open, it's about the same as Dlang, But if you 
go to the last page...

https://github.com/rust-lang/rust/pulls?page=4&q=is%3Apr+is%3Aopen

Look at that the oldest one is from October 15th, 20_17_.

Now we go to DMD...

https://github.com/dlang/dmd/pulls?page=6&q=is%3Apr+is%3Aopen

Oldest one is from January 17, 20_13_.


In contrast this same problem exists for Bugzilla. You say it's 
working cause it's better than using notepad or some other stupid 
shit. Bugzilla isn't the issue, it's the fact the people 
maintaining it aren't willing to commit to anything and leave 
issues open that shouldn't be left open. That just results in 
noise making it difficult to see what actual issues are. I'm not 
even talking about duplicate entries as you seem to have have 
misunderstood.

Iain Buclaw <ibuclaw gdcproject.org> writes:

On 30 December 2017 at 15:42, Muld via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Saturday, 30 December 2017 at 06:55:13 UTC, Walter Bright wrote:
 It's not like we have a shortage of bugzilla issues and are wondering what
 to do next.


 Yah there are a ton of Bugzilla issues, that's the problem. More than half
 of them aren't "actionable" as you put it.

There's nothing unmanageable about the issue tracker, nor are the
number of open bugs even a reliable measure of anything.  For
instance, Python has more than twice as many open bugs than D.


 Here's the problem, look at something like Rust:

 Pull requests? 95 open, it's about the same as Dlang, But if you go to the
 last page...

 https://github.com/rust-lang/rust/pulls?page=4&q=is%3Apr+is%3Aopen

 Look at that the oldest one is from October 15th, 20_17_.

 Now we go to DMD...

 https://github.com/dlang/dmd/pulls?page=6&q=is%3Apr+is%3Aopen

 Oldest one is from January 17, 20_13_.

Hey, I take offence to that.

https://issues.dlang.org/show_bug.cgi?id=17839

https://github.com/dlang/dmd/pull/7503
https://github.com/dlang/dmd/pull/7508
https://github.com/dlang/dmd/pull/7509
https://github.com/dlang/dmd/pull/7510
https://github.com/dlang/dmd/pull/7527
https://github.com/dlang/dmd/pull/7536

And many more closed that were even older, and I'm not the only one
reviving these patches, all of which are either abandoned, incomplete,
or too controversial (there is always a valid reason why open PRs were
left to rot).

 In contrast this same problem exists for Bugzilla. You say it's working
 cause it's better than using notepad or some other stupid shit. Bugzilla
 isn't the issue, it's the fact the people maintaining it aren't willing to
 commit to anything and leave issues open that shouldn't be left open. That
 just results in noise making it difficult to see what actual issues are. I'm
 not even talking about duplicate entries as you seem to have have
 misunderstood.

All open issues are actionable, and require some action.  They are not
noise, and many issues whose fix requires a change in language
specification or semantics are understandably left to the few who have
the authoritative to make such final decisions on whether it should be
accepted or rejected.

Age of issue is not a big deal.  In fact I see it as a good sign that
at least issues are left to breathe while we wait and understand the
impact or urgency of it.  As opposed to jumping in and fixing issues
immediately without taking due diligence on the wider picture it
affects.

codephantom <me noyb.com> writes:

On Saturday, 30 December 2017 at 16:36:57 UTC, Iain Buclaw wrote:
 All open issues are actionable, and require some action.  They 
 are not noise, and many issues whose fix requires a change in 
 language specification or semantics are understandably left to 
 the few who have the authoritative to make such final decisions 
 on whether it should be accepted or rejected.

 Age of issue is not a big deal.  In fact I see it as a good 
 sign that at least issues are left to breathe while we wait and 
 understand the impact or urgency of it.  As opposed to jumping 
 in and fixing issues immediately without taking due diligence 
 on the wider picture it affects.

Is this a problem with triage?

i.e. like a hositpital emergency ward chaos rules, cause nobody 
is on duty triaging.

How does a contributor prioritise their contribution to items in 
bugzilla?

Or is it perhaps a tooling problem? (i.e. bugzilla lacks features 
that are needed).

Or is it a problem with not having enough people on duty, 
triaging?

Or is it a problem with just too many patients coming in?

Or .. ??

Iain Buclaw <ibuclaw gdcproject.org> writes:

On 31 December 2017 at 02:07, codephantom via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Saturday, 30 December 2017 at 16:36:57 UTC, Iain Buclaw wrote:
 All open issues are actionable, and require some action.  They are not
 noise, and many issues whose fix requires a change in language specification
 or semantics are understandably left to the few who have the authoritative
 to make such final decisions on whether it should be accepted or rejected.

 Age of issue is not a big deal.  In fact I see it as a good sign that at
 least issues are left to breathe while we wait and understand the impact or
 urgency of it.  As opposed to jumping in and fixing issues immediately
 without taking due diligence on the wider picture it affects.


 Is this a problem with triage?

 i.e. like a hositpital emergency ward chaos rules, cause nobody is on duty
 triaging.

 How does a contributor prioritise their contribution to items in bugzilla?

Either:
1. By picking up an issue that you have a vested interest in seeing fixed.

2. Feel free to look at the list of regressons.
    https://issues.dlang.org/buglist.cgi?bug_severity=regression&component=dmd&list_id=218477&query_format=advanced&resolution=---

Bigger projects or features are delegated between the core
maintainers, or if a champion comes to take the reigns, then they have
the freedom to go ahead.  For everything else, it is pretty much a
free-for-all in terms of what you want to get fixed.  Almost nobody is
being paid to contribute to the language here.

codephantom <me noyb.com> writes:

On Sunday, 31 December 2017 at 02:06:03 UTC, Iain Buclaw wrote:
 2. Feel free to look at the list of regressons.
     
 https://issues.dlang.org/buglist.cgi?bug_severity=regression&component=dmd&list_id=218477&query_format=advanced&resolution=---

"This list is too long for Bugzilla's little mind"

Mmm..just imagine how our human mind reacts then ;-)

But... as you point out...some 'filtering' makes it 'seem' a 
little less daunting ;-)

Muld <2 2.2> writes:

On Saturday, 30 December 2017 at 16:36:57 UTC, Iain Buclaw wrote:
 Hey, I take offence to that.

 https://issues.dlang.org/show_bug.cgi?id=17839

 https://github.com/dlang/dmd/pull/7503 
 https://github.com/dlang/dmd/pull/7508 
 https://github.com/dlang/dmd/pull/7509 
 https://github.com/dlang/dmd/pull/7510 
 https://github.com/dlang/dmd/pull/7527 
 https://github.com/dlang/dmd/pull/7536

 And many more closed that were even older, and I'm not the only 
 one reviving these patches, all of which are either abandoned, 
 incomplete, or too controversial (there is always a valid 
 reason why open PRs were left to rot).


I haven't been looking recently. At least there's one vigilante 
working in the shadows, doing the things no one else is willing 
to.

Walter Bright <newshound2 digitalmars.com> writes:

On 12/30/2017 6:42 AM, Muld wrote:
 In contrast this same problem exists for Bugzilla. You say it's working cause 
 it's better than using notepad or some other stupid shit. Bugzilla isn't the 
 issue, it's the fact the people maintaining it aren't willing to commit to 
 anything and leave issues open that shouldn't be left open. That just results
in 
 noise making it difficult to see what actual issues are. I'm not even talking 
 about duplicate entries as you seem to have have misunderstood.

Anyone can contribute to bugzilla with reasoned advice about what to do with 
various issues, and can review PRs. The people responsible are, well, anyone
who 
wants to be.

Please join and help out.

IM <3di gm.com> writes:

On Sunday, 31 December 2017 at 05:43:57 UTC, Walter Bright wrote:
 On 12/30/2017 6:42 AM, Muld wrote:
 In contrast this same problem exists for Bugzilla. You say 
 it's working cause it's better than using notepad or some 
 other stupid shit. Bugzilla isn't the issue, it's the fact the 
 people maintaining it aren't willing to commit to anything and 
 leave issues open that shouldn't be left open. That just 
 results in noise making it difficult to see what actual issues 
 are. I'm not even talking about duplicate entries as you seem 
 to have have misunderstood.

 Anyone can contribute to bugzilla with reasoned advice about 
 what to do with various issues, and can review PRs. The people 
 responsible are, well, anyone who wants to be.

 Please join and help out.

While we are discussing it here, could you please let me know 
what the bug triage process for each release cycle is? Is it 
random that anyone picks up whatever bug s/he feels like fixing? 
Or is it that if contributors will contribute X number of patches 
this cycle, then there is some sort of guidance and direction of 
this effort towards fixing some high priority bugs?

Walter Bright <newshound2 digitalmars.com> writes:

On 12/30/2017 11:23 PM, IM wrote:
 While we are discussing it here, could you please let me know what the bug 
 triage process for each release cycle is? Is it random that anyone picks up 
 whatever bug s/he feels like fixing? Or is it that if contributors will 
 contribute X number of patches this cycle, then there is some sort of guidance 
 and direction of this effort towards fixing some high priority bugs?

Bugs are ranked by severity, but generally what gets fixed are bugs that a 
particular person self-selects an interest in fixing it.

Often people who just want to help out will peruse the buglist looking for 
issues that match their skill levels that they can fix.

IM <3di gm.com> writes:

On Sunday, 31 December 2017 at 07:43:35 UTC, Walter Bright wrote:
 On 12/30/2017 11:23 PM, IM wrote:
 While we are discussing it here, could you please let me know 
 what the bug triage process for each release cycle is? Is it 
 random that anyone picks up whatever bug s/he feels like 
 fixing? Or is it that if contributors will contribute X number 
 of patches this cycle, then there is some sort of guidance and 
 direction of this effort towards fixing some high priority 
 bugs?

 Bugs are ranked by severity, but generally what gets fixed are 
 bugs that a particular person self-selects an interest in 
 fixing it.

 Often people who just want to help out will peruse the buglist 
 looking for issues that match their skill levels that they can 
 fix.

I hope that you could see that this doesn't scale very well, and 
some kind of a process needs to be established to shape and 
direct the efforts. Some thoughts/suggestions:
- Weekly meeting to review open bugs, adjust their components and 
priority appropriately, and assign to potential owners (those who 
can or likely to fix the bugs. Owners can then reassign or 
unassign if not interested).
- Maybe ask someone to volunteer for triaging bugs in each 
component. So every component has an owner.
- If a bug has been assigned to someone and hasn't received any 
attention (i.e. remained open for say 3 months), a bot should 
unassign it so that it returns back to the triage pool, hoping 
that it will catch the attention of the triage volunteers.

What do you think? Do you agree that a process is needed?

Walter Bright <newshound2 digitalmars.com> writes:

On 12/31/2017 8:18 AM, IM wrote:
 What do you think? Do you agree that a process is needed?

We've tried adding process before. It does not work, for the simple reason that 
it requires a dedicated group of people to dedicate time to it. Are you willing 
to do that?

We have added process when someone has stepped up to do the thankless job of 
administering it.

codephantom <me noyb.com> writes:

On Sunday, 31 December 2017 at 21:16:35 UTC, Walter Bright wrote:
 On 12/31/2017 8:18 AM, IM wrote:
 What do you think? Do you agree that a process is needed?

 We've tried adding process before. It does not work, for the 
 simple reason that it requires a dedicated group of people to 
 dedicate time to it. Are you willing to do that?

 We have added process when someone has stepped up to do the 
 thankless job of administering it.

Well, I've spent the last few months just learning the language, 
debating issues on this forum, and fending off the occasional 
attack. This is probably what most newcomers will go through too..

For the most part, I think D is a really nice language to 'play' 
with, and thanks to all those that have made it happen.

Now as I think about moving from just playing with D, to making 
serious use of it, this lack of 'process' you mention, could 
become a real deal breaker.

The D Foundation should take this matter very seriously, in my 
opinion, and invest in process, rather than just hoping it will 
emerge out of the chaos of bugzilla.

By not focusing your attention on this more, I believe you risk a 
lot of people refusing to contribute to D, and even turning away 
from D. You also risk fragmentation in the D community.

Now, that asisde, happy New Year to you, and all.

Lets' make it a great year to advance D even further...

IM <3di gm.com> writes:

On Sunday, 31 December 2017 at 21:16:35 UTC, Walter Bright wrote:
 On 12/31/2017 8:18 AM, IM wrote:
 What do you think? Do you agree that a process is needed?

 We've tried adding process before. It does not work, for the 
 simple reason that it requires a dedicated group of people to 
 dedicate time to it.

Something should work. It just needs to be found. People are 
already dedicating time to D by contributing fixes and filing 
issues, responding on the forums, ... etc. Organizing work and 
priorities is not an exception. It doesn't take that long by the 
way, only 30 ~ 60 minutes per week max should be more than 
enough. I hope you could take the upcoming DConf as an 
opportunity to discuss with others ways to enhance the process 
and minimize friction.


 Are you willing to do that?

I'd be happy to do it, but I'm not the right person for it. This 
needs someone who knows D very well, knows the bigger picture, 
and is familiar with the contributors and who mostly works on 
what to be able to adjust priorities and ownership appropriately. 
I've been learning and experimenting with D only for a few 
months. Also, I'm worried about - though unlikely - to put myself 
in a conflict-of-interest situation; we don't use D at work, and 
as far as I know there are neither interest nor plans to do so. I 
hope this will change one day, and that's why I started this 
post, because quality and maturity are very important.

 We have added process when someone has stepped up to do the 
 thankless job of administering it.

I think it is thankful and as important as submitting PRs and 
DIPs. Shaping, organizing, and directing human effort are just as 
important as the human effort itself.

Muld <2 2.2> writes:

On Sunday, 31 December 2017 at 05:43:57 UTC, Walter Bright wrote:
 Please join and help out.

I already have, and like I said there are problems with with the 
current system. I don't feel like helping anymore cause anything 
time I do my work just get dumped, and I've simply wasted my time.

 Bugs are ranked by severity, but generally what gets fixed are 
 bugs that a particular person self-selects an interest in 
 fixing it.

 Often people who just want to help out will peruse the buglist 
 looking for issues that match their skill levels that they can 
 fix.

You've just admitted to the problem. And those that want to "help 
out" will "persue the buglist looking for issues".

Then you drop this quote, "it's fine for those that want to put 
in a wasteful time of effort, cause they care enough".

 It's working well enough for those who care enough to make an 
 effort.

Fix your shit if you want help, it's broken and just wastes 
people's time. Saying that people don't care enough is not 
helping with a solution.

Walter Bright <newshound2 digitalmars.com> writes:

On 12/31/2017 12:53 PM, Muld wrote:
 Fix your shit

A word to the wise. Being rude will just get you ignored by most everyone on 
this n.g. We insist on professional demeanor and courtesy at all times. 
Egregious behavior will get posts unceremoniously removed.

Binghoo Dang <dangbinghoo gmail.com> writes:

On Sunday, 31 December 2017 at 20:53:37 UTC, Muld wrote:
 ...

Stop making noise except one-day you make another well-known 
language popular in the world called E.

What a kind of people who you are ? and can make such a noise to 
well known and famous person who made such a great language?


And, everyone who's making noise just stop. If you don't like D, 
just go to Go or Rust. The community is just kindly making 
opensource project which means they are contributing times and 
life to the human. and what you do except making noise?

And Dear Walter is working for D all the time, Didn't anyone seen 
he is merging PRs on github?

So, let's be calm and graceful, that is if you consider there's 
problem, just fix it. Or provides more detailed information for 
the core team to fix it. Not just saying "D is bad on this or 
that".

And at least, keep polite if you're not a guy like Bill Gates or 
Jobs.

Meta <jared771 gmail.com> writes:

On Saturday, 30 December 2017 at 14:42:45 UTC, Muld wrote:
 On Saturday, 30 December 2017 at 06:55:13 UTC, Walter Bright 
 wrote:
 It's not like we have a shortage of bugzilla issues and are 
 wondering what to do next.

 Yah there are a ton of Bugzilla issues, that's the problem. 
 More than half of them aren't "actionable" as you put it.

 Here's the problem, look at something like Rust:

 Pull requests? 95 open, it's about the same as Dlang, But if 
 you go to the last page...

 https://github.com/rust-lang/rust/pulls?page=4&q=is%3Apr+is%3Aopen

 Look at that the oldest one is from October 15th, 20_17_.

 Now we go to DMD...

 https://github.com/dlang/dmd/pulls?page=6&q=is%3Apr+is%3Aopen

 Oldest one is from January 17, 20_13_.

This is a problem that many of us are working on fixing. The main 
reason many of these old zombie PRs stick around is that 
historically, people are hesitant to close things (for a variety 
of social reasons, I feel). While there is still the slightest 
chance that something might someday be merged, it is kept open. 
Rust is a lot more aggressive about closing bad or outdated PRs 
and either guiding PRs that need work to get to a mergeable 
state, or closing them and communicating that this is not the 
correct way to go. I watched a talk by a Rust contributor 
specifically on this point awhile ago - they have a bot that does 
a lot of the PR closure work to get around the fact that people 
are hesitant to be the "bad guy" and tell someone that their work 
is not good enough. D needs to get much better at this, and I 
think things are happening - slowly. The bad optics and 
demoralizing effect of letting things sit forever without 
definitive action outweighs the potential loss from being more 
aggressive about closing or merging.

Seb <seb wilzba.ch> writes:

On Sunday, 31 December 2017 at 09:37:35 UTC, Meta wrote:
 On Saturday, 30 December 2017 at 14:42:45 UTC, Muld wrote:
 On Saturday, 30 December 2017 at 06:55:13 UTC, Walter Bright 
 wrote:
 It's not like we have a shortage of bugzilla issues and are 
 wondering what to do next.

 Yah there are a ton of Bugzilla issues, that's the problem. 
 More than half of them aren't "actionable" as you put it.

 Here's the problem, look at something like Rust:

 Pull requests? 95 open, it's about the same as Dlang, But if 
 you go to the last page...

 https://github.com/rust-lang/rust/pulls?page=4&q=is%3Apr+is%3Aopen

 Look at that the oldest one is from October 15th, 20_17_.

 Now we go to DMD...

 https://github.com/dlang/dmd/pulls?page=6&q=is%3Apr+is%3Aopen

 Oldest one is from January 17, 20_13_.

 This is a problem that many of us are working on fixing. The 
 main reason many of these old zombie PRs stick around is that 
 historically, people are hesitant to close things (for a 
 variety of social reasons, I feel). While there is still the 
 slightest chance that something might someday be merged, it is 
 kept open. Rust is a lot more aggressive about closing bad or 
 outdated PRs and either guiding PRs that need work to get to a 
 mergeable state, or closing them and communicating that this is 
 not the correct way to go. I watched a talk by a Rust 
 contributor specifically on this point awhile ago - they have a 
 bot that does a lot of the PR closure work to get around the 
 fact that people are hesitant to be the "bad guy" and tell 
 someone that their work is not good enough. D needs to get much 
 better at this, and I think things are happening - slowly. The 
 bad optics and demoralizing effect of letting things sit 
 forever without definitive action outweighs the potential loss 
 from being more aggressive about closing or merging.

Yes, Dlang-bot was able to detect stalled issues for a while, but 
we didn't turn this on for all repositories. I have just enabled 
it:

https://github.com/dlang-bots/dlang-bot/pull/153

For the moment, it is just labelling issues with e.g. "needs 
work", "needs rebase", "stalled", "stalled-stable".
In a next stage it will start to actively ping people or close 
PRs.
Also automatically rebasing PRs if there are no conflicts is on 
the radar (the GitHub UI is quite conservative in this regard).

Meta <jared771 gmail.com> writes:

On Sunday, 31 December 2017 at 11:27:41 UTC, Seb wrote:
 Yes, Dlang-bot was able to detect stalled issues for a while, 
 but we didn't turn this on for all repositories. I have just 
 enabled it:

 https://github.com/dlang-bots/dlang-bot/pull/153

 For the moment, it is just labelling issues with e.g. "needs 
 work", "needs rebase", "stalled", "stalled-stable".
 In a next stage it will start to actively ping people or close 
 PRs.
 Also automatically rebasing PRs if there are no conflicts is on 
 the radar (the GitHub UI is quite conservative in this regard).

Awesome. Thanks for all your hard work on the automation side of 
things, by the way. It's not glamorous but it's a huge force 
multiplier.

Walter Bright <newshound2 digitalmars.com> writes:

On 12/29/2017 5:40 PM, Adam D. Ruppe wrote:
 [...]

PRs to fix bugzilla issues get submitted every day. I don't see a better way. I 
can't monitor every forum, I rely on you and others to do so and submit the
issues.

Muld <2 2.2> writes:

On Friday, 29 December 2017 at 21:30:35 UTC, Walter Bright wrote:
 On 12/29/2017 9:29 AM, Adam D. Ruppe wrote:
 On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
    -- Better compiler errors, better compiler errors, better 
 compiler errors.

 
 
 This is the only thing I greatly care about anymore. Biggest 
 problem D has in real world use.

 This is not actionable. What is actionable is filing bugzilla 
 enhancement requests with specific examples.

Bugzilla is a huge mess tbh, creating a request in bugzilla won't 
lead anywhere. There's so many pointless entries in there people 
have to waste their time looking through just to see what is and 
isn't "actionable" (as you put it). I was thinking of making a 
senseless entry that had some fake example code and see how long 
it would take for the entry to be closed/removed. Something tells 
me it would never be closed/removed.

The barrier for what constitutes a bugzilla entry and why it can 
remain open should be stricter. For example anything that is an 
"enhancement" and would require a DIP should not remain open. 
Bugzilla shouldn't be a "wishlist" for Dlang. This just adds 
needless bloat, what's worse is when an enchantment is not 
labelled that it needs a DIP and someone goes wasting their time 
implementing it.

It's so bad honestly it'd probably be less work just to create a 
new bugzilla and port any relevant entries from the current one.

Walter Bright <newshound2 digitalmars.com> writes:

On 12/29/2017 3:15 PM, Muld wrote:
 Bugzilla is a huge mess tbh, creating a request in bugzilla won't lead
anywhere.

Fixes for bugzilla issues are posted on github nearly every day.


 It's so bad honestly it'd probably be less work just to create a new bugzilla 
 and port any relevant entries from the current one.

It's not a big deal to create a duplicate of existing entries. As to bugzilla 
itself, despite its issues, it is far far far better and more organized than 
randomly looking in chat rooms, stack overflow, newsgroups, etc.

Muld <2 2.2> writes:

On Friday, 29 December 2017 at 23:27:38 UTC, Walter Bright wrote:
 On 12/29/2017 3:15 PM, Muld wrote:
 Bugzilla is a huge mess tbh, creating a request in bugzilla 
 won't lead anywhere.

 Fixes for bugzilla issues are posted on github nearly every day.

This does not mean anything, just cause fixes for Bugzilla issues 
are being fixed "nearly every day" is not part of the larger 
problem. The people that are pushing fixes for those issues tend 
to be the same people that are creating them. Sure I can create a 
bugzilla issue, but unless I'm the one that creates a fix for it, 
it probably won't be fixed unless it is a regression.

 It's so bad honestly it'd probably be less work just to create 
 a new bugzilla and port any relevant entries from the current 
 one.

 It's not a big deal to create a duplicate of existing entries. 
 As to bugzilla itself, despite its issues, it is far far far 
 better and more organized than randomly looking in chat rooms, 
 stack overflow, newsgroups, etc.

Living on Mars is far far better than trying to live on the 
surface of the Sun. Just cause that's the case doesn't mean you 
should stop looking for a place called Earth.

IM <3di gm.com> writes:

On Friday, 29 December 2017 at 17:29:47 UTC, Adam D. Ruppe wrote:
 On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
    -- Better compiler errors, better compiler errors, better 
 compiler errors.


 This is the only thing I greatly care about anymore. Biggest 
 problem D has in real world use.

Please allow me to give an example of how first impressions of 
maturity really matter! Recently at some company, a group of 
engineers started advocating for using Rust. They wrote a doc 
explaining the differences and benefits of Rust over C++ (which 
is heavily used). People started experimenting, and immediately 
the maturity and good user experience of rustc and cargo were 
quite obvious. The result was that Rust is now more appealing, 
some new projects were written in Rust, some old ones have or are 
being migrated from C++ to Rust.

(**This is a real story by the way**)

Now, given the fact that I love D despite some of the annoying 
issues I encounter with it frequently, I would like to call my 
colleagues to give it a try and experiment with it. People start 
getting interested. They start writing some code, and eventually 
they hit one of those unhelpful compile error messages, which 
could indicate one of the following:
- An error in the engineer's knowledge of the language which the 
compiler didn't help to understand what it is so that s/he goes 
to look it up.
- A bug in Phobos.
- An actual compiler bug or inconsistency.

Remember, those engineers are experimenting with D to use it for 
serious projects at work, not personal toy projects. What do you 
think? Is it likely that they decide to invest a lot of time and 
resources migrating projects to D?

Maturity (or at least approaching it as much as possible) is VERY 
VERY VERY important.

I like what the D foundation did to the website, the language and 
library docs, the Learn section, the forums, the resources ... 
etc. That definitely gives the impression of maturity.

Looking forward to seeing more of that in the compiler, which is 
the single most important thing in a programming language, the 
reason it exists, the thing I interface with most of the time.

Walter Bright <newshound2 digitalmars.com> writes:

On 12/29/2017 7:07 PM, IM wrote:
 They start writing 
 some code, and eventually they hit one of those unhelpful compile error 
 messages, which could indicate one of the following:
 - An error in the engineer's knowledge of the language which the compiler
didn't 
 help to understand what it is so that s/he goes to look it up.
 - A bug in Phobos.
 - An actual compiler bug or inconsistency.

I'm sorry, there is literally nothing I can do with that. To get action, you 
need to be specific.

ag0aep6g <anonymous example.com> writes:

On 12/30/2017 04:07 AM, IM wrote:
 I like what the D foundation did to the website, the language and 
 library docs, the Learn section, the forums, the resources ... etc. That 
 definitely gives the impression of maturity.

As far as I'm aware, the foundation isn't too active in those areas; 
unless Vladimir or Seb are on their payroll now. Maybe the foundation 
pays the electricity bills, but the work is done by volunteers.

Laeeth Isharc <laeeth laeeth.com> writes:

On Saturday, 30 December 2017 at 03:07:57 UTC, IM wrote:
 On Friday, 29 December 2017 at 17:29:47 UTC, Adam D. Ruppe 
 wrote:
 On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
    -- Better compiler errors, better compiler errors, better 
 compiler errors.


 This is the only thing I greatly care about anymore. Biggest 
 problem D has in real world use.

 Please allow me to give an example of how first impressions of 
 maturity really matter! Recently at some company, a group of 
 engineers started advocating for using Rust. They wrote a doc 
 explaining the differences and benefits of Rust over C++ (which 
 is heavily used). People started experimenting, and immediately 
 the maturity and good user experience of rustc and cargo were 
 quite obvious. The result was that Rust is now more appealing, 
 some new projects were written in Rust, some old ones have or 
 are being migrated from C++ to Rust.

 (**This is a real story by the way**)

 Now, given the fact that I love D despite some of the annoying 
 issues I encounter with it frequently, I would like to call my 
 colleagues to give it a try and experiment with it. People 
 start getting interested. They start writing some code, and 
 eventually they hit one of those unhelpful compile error 
 messages, which could indicate one of the following:
 - An error in the engineer's knowledge of the language which 
 the compiler didn't help to understand what it is so that s/he 
 goes to look it up.
 - A bug in Phobos.
 - An actual compiler bug or inconsistency.

 Remember, those engineers are experimenting with D to use it 
 for serious projects at work, not personal toy projects. What 
 do you think? Is it likely that they decide to invest a lot of 
 time and resources migrating projects to D?

 Looking forward to seeing more of that in the compiler, which 
 is the single most important thing in a programming language, 
 the reason it exists, the thing I interface with most of the 
 time.


 Remember, those engineers are experimenting with D to use it 
 for serious projects at work, not personal toy projects. What 
 do you think? Is it likely that they decide to invest a lot of 
 time and resources migrating projects to D?

Then probably you did the right thing in not suggesting they move 
to using D at work at the current time.

There are all kinds of coordination costs in adopting D 
immediately for serious projects where the people involved don't 
know the language yet and where the benefits of D don't seem 
compelling at this point.

It's much better if the people involved start using D on the side 
for things that aren't mission critical or that don't have a 
tight deadline, unless D solves a particular sort of problem you 
have or theres much receptivity to it.

I don't think D is at a point where it should be sold.  People 
need to be receptive and ready to move towards you.  And they 
need to be able to take decisions on the basis of intrinsic 
merits and not have to consider social factors.  They means that 
the natural sphere of adoption is startups run by creative and 
independent minded people, smaller firms and small groups within 
large firms where people have autonomy.  That's really quite okay 
- in the US, more than 100% of new jobs are created by smaller 
firms.

Its a mistake to use a language you don't know for a mission 
critical project with a tight deadline, unless it solves so many 
problems that it is worth the inevitable teething problems.  
Doing so is a recipe for brittleness because it's hard to 
anticipate any difficulties and hard to plan for them.

D naturally is spread much thinner than many other languages 
because it's more ambitious and is useful for many different 
domains, so if you're in a particular one of them then you will 
know many fewer people using D then would be the case for 
languages that are more adapted for particular domains.

Also, there's much difference in how much people in different 
areas tend to talk about what they are doing.  Web guys talk a 
lot; finance guys not do much. The people I have met who use D at 
work mostly don't develop open source stuff at work and they 
don't post all that much in the forums.

We are rewriting our core analytics used across the firm (about 
95 people) to D.  Why? Because they need to be accessible from 
other languages so C ABI is necessary and it's not even a 
contest, D vs C++.  And the person in charge of that project is a 
Fellow in Maths at Cambridge, and the one helping him is also a 
Cambridge mathematician so they realise how important beauty is 
in taming complexity, and D does exceptionally well on that 
front.  We can then programmatically generate wrappers for other 
languages and we can connect the analytics and some micro 
services with a little domain specific language written using 
pegged.

So it's highly unusual sets of people like that, or like the 
founders of Sociomantic, or like the EMSI guys, or Liran's guys 
at Weka that are likely to be D adopters in the next wave. Not 
people who can't see through error messages (which are much 
better than C++ anyway).

 I like what the D foundation did to the website, the language 
 and library docs, the Learn section, the forums, the resources 
 ... etc. That definitely gives the impression of maturity.

I'm not sure those changes were primarily a consequence of things 
the D Foundation did, though maybe I'm wrong.

You know how the runnable examples appeared? Seb Wilzbach, who 
appeared out of nowhere, decided to make them happen.  Initially 
people didn't even see the point of them and there was some 
modest resistance.

 Maturity (or at least approaching it as much as possible) is 
 VERY VERY VERY important.

D is rough around the edges as an ecosystem.  That's because the 
people involved care deeply about technical things and less so 
about making things incredibly comfortable for new users.  
Language ecosystems have difjferent values - when you pick a 
language you're marrying into that ecosystem, and whether it's 
right for you depends on the values you hold.

The cost of that is obvious, but the benefit comes in other ways, 
including the capabilities of the set of people involved with D. 
That D isn't a shiny thing for now does act as a filter to 
discourage people who can't see through that.

I don't think you can act mature when you aren't.  In time D 
ecosystem will be mature and we will be reminiscing about those 
days when one could know the people involved and it was intrinsic 
rather than career motivation that attracted newcomers.  For the 
time being that isn't the case, so one has to pick one's poison 
and decide what's important. Maybe for those who can't recognise 
what D offers at this point, D isn't the language for them and 
they should try Rust or Go.

Maturity for the ecosystem will come.. In the meantime taking 
action or giving money is a much more effective way to shape 
things than saying "you know what you should do if you were a 
billionaire is this".  It would be nice to have more resources - 
one could do things with them, but for the time being one is 
where one is, so suggesting that the Foundation should do X or Y 
isn't likely to have nearly as much impact as figuring out one 
tiny step towards it and becoming in part the change you wish to 
see.

Maturity of the language is something else.  The compilers seem 
quite usable - in 2014 I would regularly have segfaults and 
that's rare these days. The documentation has gone from being 
terrifying to non sophisticated programmers to my being able to 
say to colleagues we should have documentation as good as 
this,and runnable examples is good motivation to write unit tests 
too.

I agree that better error messages would be nice.  They're 
already a lot better, and I guess that will continue.

Paolo Invernizzi <paolo.invernizzi gmail.com> writes:

On Friday, 5 January 2018 at 01:29:04 UTC, Laeeth Isharc wrote:

 So it's highly unusual sets of people like that, or like the 
 founders of Sociomantic, or like the EMSI guys, or Liran's guys 
 at Weka that are likely to be D adopters in the next wave. Not 
 people who can't see through error messages (which are much 
 better than C++ anyway).

+1000

I would add that D should leverage the fact that is a "company 
friendly" language: the core team cares about problems raised by 
commercials that are using it (or, at least, it try hard to do 
it! :-P).

That's pretty unique, in that phase of his history, compared to 
what we can see around.

Well, it should do this in a more structured way, as I've 
suggested to Andrei, but it's definitely a big plus.

/Paolo

Neia Neutuladh <neia ikeran.org> writes:

On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
    -- Better compiler errors, better compiler errors, better 
 compiler errors.

Very much so.

I actually made a list a day or two ago. Some of it is more 
speculative than concrete, though:

* unicode categories to determine what can be an identifier 
(there's no reason not to support, say, Canadian aboriginal 
syllabaries; it would just be too much work to list out each 
range of glyphs)
* concepts / compile-time interfaces (makes ranges easier to deal 
with and document)
*  safe by default
* function parameters are const scope by default (I recall this 
was a major request when const was first introduced)
* mixin templates (a template designed to be mixed in is likely 
not to work if simply invoked; this also gets us most of what 
people have been asking for with macros)
* possibly, block syntax for functions and templates whose last 
parameter is a function or alias

Walter Bright <newshound2 digitalmars.com> writes:

On 12/28/2017 11:53 PM, IM wrote:
 Simple things like these make a big difference. D Lang has been around for a 
 long while now, and hence signs of its maturity has to show everywhere, 
 especially in the compiler, as well as the package manager.

Diverging from the:

   file(line): message

format is problematic because a lot of editors rely on that to position the 
editor on the offending line.

Seb <seb wilzba.ch> writes:

On Friday, 29 December 2017 at 21:34:14 UTC, Walter Bright wrote:
 On 12/28/2017 11:53 PM, IM wrote:
 Simple things like these make a big difference. D Lang has 
 been around for a long while now, and hence signs of its 
 maturity has to show everywhere, especially in the compiler, 
 as well as the package manager.

 Diverging from the:

   file(line): message

 format is problematic because a lot of editors rely on that to 
 position the editor on the offending line.

It's easy to detect whether the compiler is invoked in a TTY.
Even if this turns out to be tricky, showing more helpful 
information to the user with a special flag (e.g. `--explain` or 
`--detailed`) is a way to go forward.

Atila Neves <atila.neves gmail.com> writes:

On Friday, 29 December 2017 at 21:56:26 UTC, Seb wrote:
 On Friday, 29 December 2017 at 21:34:14 UTC, Walter Bright 
 wrote:
 On 12/28/2017 11:53 PM, IM wrote:
 Simple things like these make a big difference. D Lang has 
 been around for a long while now, and hence signs of its 
 maturity has to show everywhere, especially in the compiler, 
 as well as the package manager.

 Diverging from the:

   file(line): message

 format is problematic because a lot of editors rely on that to 
 position the editor on the offending line.

 It's easy to detect whether the compiler is invoked in a TTY.
 Even if this turns out to be tricky, showing more helpful 
 information to the user with a special flag (e.g. `--explain` 
 or `--detailed`) is a way to go forward.

Being in an editor does not imply being in a TTY.

Atila

rjframe <dlang ryanjframe.com> writes:

On Fri, 29 Dec 2017 13:34:14 -0800, Walter Bright wrote:

 On 12/28/2017 11:53 PM, IM wrote:
 Simple things like these make a big difference. D Lang has been around
 for a long while now, and hence signs of its maturity has to show
 everywhere, especially in the compiler, as well as the package manager.

 
 Diverging from the:
 
    file(line): message
 
 format is problematic because a lot of editors rely on that to position
 the editor on the offending line.

I think the idea of the OP is that the message should be better; not that 
it should have an identical format to the Rust error.

    file(line): better message

isn't going to mess with anybody's tools.

I noticed the Rust error has a code, too (E0308); if better error messages 
are too difficult to implement, assigning codes to error types and 
documenting them on the wiki could be helpful. Once you've dealt with an 
error type, the messages aren't that bad, but having documentation for the 
first time you run into it would be nice.

Somewhat-related question out of curiosity: is there ever a time the error 
message "template instance foo!(bar) error instantiating" is actually 
needed? I've always seen it paired with a message that actually describes 
the problem, so is just noise.

Walter Bright <newshound2 digitalmars.com> writes:

On 12/29/2017 1:57 PM, rjframe wrote:
 I noticed the Rust error has a code, too (E0308); if better error messages
 are too difficult to implement, assigning codes to error types and
 documenting them on the wiki could be helpful. Once you've dealt with an
 error type, the messages aren't that bad, but having documentation for the
 first time you run into it would be nice.

Many compilers produce such error codes. I've considered it many times, but 
eventually concluded it added negative value.

1. Typing in an error code is so 1980's :-) People expect better these days.

2. A list of error messages with explanations can be trivially searched with a 
simple 'find text' command, which is much easier than typing in an error code.

3. Ideally there'd be a url one could click on, not an error code.

4. It's ugly.


 Somewhat-related question out of curiosity: is there ever a time the error
 message "template instance foo!(bar) error instantiating" is actually
 needed?

Yes. It shows where the error originates in the user's code.

codephantom <me noyb.com> writes:

On Friday, 29 December 2017 at 23:32:45 UTC, Walter Bright wrote:
 ...
 3. Ideally there'd be a url one could click on, not an error 
 code.
 ....

No URLs! (unless they point to 'local' documentation).

I do not want to become even more dependent on having access to 
the internet, in order to debug programs.

radagast <brucewayneshit gmail.com> writes:

On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
 I will start:

    -- Better compiler errors, better compiler errors, better 
 compiler errors.


 I really wish that the compiler errors could receive some 
 refinement. Mostly it feels like some error text just being 
 thrown at me. It needs to be better formatted, more helpful, 
 with suggestions about how to fix (if possible).

 To illustrate my point:

 - See the compile errors I've just encountered with DMD: 
 https://cdn.pbrd.co/images/H0q609l.png

 - Now compare that with an error produced by rustc:
 https://cdn.pbrd.co/images/H0q6bLi.png


 Simple things like these make a big difference. D Lang has been 
 around for a long while now, and hence signs of its maturity 
 has to show everywhere, especially in the compiler, as well as 
 the package manager.

* R-value references.
* More "Hands free" package/dependency management (See 
Cargo(Rust))
* GC dependency free stdlib, with built-in general purpose async 
i/o library
* More sophisticated, official language server
* Better IDE support
* Full-fledged smart pointer (resembling std::unique_ptr<T>, 
std::shared_ptr<T>, std::weak_ptr<T> in the standard
* Riddance of `object`, and being able to hand-make rootobject. 
No common root class.