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.

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.

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

I'm missing Kenji...

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

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

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.

On Thursday, 4 January 2018 at 18:27:37 UTC, H. S. Teoh wrote:
> So, one can choose to be part of the noise, or part of the real work. If you don't like the way certain things are done, then step up and do it differently.

I hear this argument too much in the D community. It is not the solution D needs.

Plenty of people are willing to step up.

The problem, as I see it, is a lack of process to ensure such peoples efforts are worthwhile.

I volunteer in the community (nothing to do with computing), and I only volunteer with organisations that have clear strategic goals, well defined processes, and good management. These things form a vital framework that encourages and retains volunteers, and the best of them too.

The open souce development model is all about volunteers... I get that...but from what I can tell, it often lacks such a necessary framework... and this becomes self evident over time.

I do not see it as the responsibility of volunteers to create such a framework. This should be motivated and sponsered by core, just as it would in a real world scenario.


> And how are you measuring software quality?

By looking for that essential framework I mentioned previously.


>
>> 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.
>
> That's a decision for the D Foundation to make, not for us.

Indeed!

> Nonsense. All real-world software have thousands of bugs. If you're lucky, that is. Most have a lot more than that. Today's software is complex enough that many of these bugs are non-trivial to fix. It does not necessarily correspond with the lack (or not) of QA.

Rubbish. QA and number of bugs are correlated.

>
> You seem to have an overly-simplified, idealistic view of QA. In my experience, the existence of a QA department does little in terms of actually eradicating bugs from software. What it does, especially in an enterprise environment, is to encourage coders to hide problems because they don't want the QA people to constantly be breathing down their necks about long-standing bugs that are non-trivial to fix. It's either that, or they are motivated to implement quick-n-dirty hacks instead of addressing the fundamental problem, because they just don't want to deal with the issue right now and implementing hacks instead of real solutions keeps the bug count down (makes them look good and makes the managers happier), keeps QA off their backs, and keeps them on schedule against unreasonable deadlines.

Those coders are working for the wrong company.


> Now I'm not saying D doesn't need to improve its QA process -- that would be quite welcome, in fact.

Finally! We agree!

> Unfortunately, the fact of the matter is that software is complex, and especially in this day and age, of a scale where the complexity is beyond an ordinary person's ability to fully grasp. Anyone who tells you otherwise has no idea what they're talking about, and/or is trying to sell you snake oil.

Hence the need for QA.

> When you have a whole bunch of people contributing changes, the existence of bugs is almost an inescapable fact.

Hence the need for QA.


> One can look at this from the pessimist's point-of-view, that all software is hopelessly buggy and we might as well give up now, or one can look at this from the opportunist's point-of-view, that there is much room for improvement, much room to make meaningful contributions, and much space to go much farther than we already have.

QA is optimistic, not pessimitic.

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.

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

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.