www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Under 1000 opened bugs for Phobos

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
https://goo.gl/r24Izw

Some of them are D1 only; I'll make an executive decision about those 
soon. Some of them have been fixed or obviated by recent improvements. 
And finally the bulk of them need a little work each to get them fixed.

I'm thinking this has crowdsourcing written all over it. It would be 
great if many of us made one pass through the list and take a look at 
bugs with an eye for cleaning up the list.


Andrei
Nov 03 2015
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/03/2015 09:35 AM, Andrei Alexandrescu wrote:

 https://goo.gl/r24Izw

 Some of them are D1 only; I'll make an executive decision about those soon.


After speaking to Don I am closing D1-only Phobos bugs with "wontfix". 
If anyone wants to work on specific bugs, please reopen. Thanks! -- Andrei
Nov 03 2015
prev sibling next sibling parent reply Jeffery <Jeffery gmail.com> writes:
On Tuesday, 3 November 2015 at 14:35:08 UTC, Andrei Alexandrescu 
wrote:

 https://goo.gl/r24Izw

 Some of them are D1 only; I'll make an executive decision about 
 those soon. Some of them have been fixed or obviated by recent 
 improvements. And finally the bulk of them need a little work 
 each to get them fixed.

 I'm thinking this has crowdsourcing written all over it. It 
 would be great if many of us made one pass through the list and 
 take a look at bugs with an eye for cleaning up the list.


 Andrei



It would be nice if there was a very good tutorial that shows 
exactly how to contribute to D.

I don't have the time to spend days figuring out how to get it 
all to work, etc but I could spend a few mins a day contributing 
to bugs and such.

Would it be beneficial for someone to create an official video 
and documentation to help get people to contribute easily and 
correctly?

e.g., I'm thinking of something like this:

1. Watch video, without too much nonsense, that explains the 
process
2. Download the distribution.
3. Apply what was in video(e.g., a simple example of fixing a bug)
4. Contribute FTW.

Anything getting in the way is a downer. I don't want to spend 4 
hours trying to figure out why the source won't compile. I've got 
better things to do with my time. If I'm reasonably confident 
that I can follow a simple and exact procedure that almost surely 
would work, then I'm more likely to go down that path.


I think it would benefit D to have such things. But only those 
"in the know" can accomplish the task.

(also, these captchas suck!!, every time I post, it says I have 
to wait 15 sec to repost: "Your last post was less than 15 
seconds ago. Please wait a few seconds before trying again."... 
and that's after I answer the captcha correctly, which I then 
have to answer again!)
Nov 03 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/03/2015 02:36 PM, Jeffery wrote:

 On Tuesday, 3 November 2015 at 14:35:08 UTC, Andrei Alexandrescu wrote:

 https://goo.gl/r24Izw

 Some of them are D1 only; I'll make an executive decision about those
 soon. Some of them have been fixed or obviated by recent improvements.
 And finally the bulk of them need a little work each to get them fixed.

 I'm thinking this has crowdsourcing written all over it. It would be
 great if many of us made one pass through the list and take a look at
 bugs with an eye for cleaning up the list.


 Andrei



 It would be nice if there was a very good tutorial that shows exactly
 how to contribute to D.


I wrote this: http://wiki.dlang.org/Starting_as_a_Contributor, is it 
what you need it to be? -- Andrei
Nov 03 2015
next sibling parent NVolcz <niklas.volcz gmail.com> writes:
On Tuesday, 3 November 2015 at 19:42:58 UTC, Andrei Alexandrescu 
wrote:

 On 11/03/2015 02:36 PM, Jeffery wrote:
 I wrote this: http://wiki.dlang.org/Starting_as_a_Contributor, 
 is it what you need it to be? -- Andrei


Windows instructions (We exclude quite many possible contributors 
because of this) (same for the building instructions)
Nov 03 2015
prev sibling next sibling parent Gary Willoughby <dev nomad.so> writes:
On Tuesday, 3 November 2015 at 19:42:58 UTC, Andrei Alexandrescu 
wrote:

 I wrote this: http://wiki.dlang.org/Starting_as_a_Contributor, 
 is it what you need it to be? -- Andrei


There's also these:

http://wiki.dlang.org/Building_DMD
http://wiki.dlang.org/Pull_Requests
Nov 03 2015
prev sibling next sibling parent reply Chris <wendlec tcd.ie> writes:
On Tuesday, 3 November 2015 at 19:42:58 UTC, Andrei Alexandrescu 
wrote:


 I wrote this: http://wiki.dlang.org/Starting_as_a_Contributor, 
 is it what you need it to be? -- Andrei


"Then, github detects the new code and offers assistance to 
create a pull request with just a couple of clicks."

The problem is when your own branch is a few weeks/months old. 
Then you have to do some upstream/update etc. magic. It happened 
to me once or twice. It put me off a bit, although I only fixed 
typos and trivial stuff like that.

It's not D, it's git(hub) that makes things complicated. It'd be 
good if you could just update your own branch on github (refork 
it or whatever) and then clone it onto your own machine. But it's 
not that straight forward.

PS Jeffery, the first steps are really easy. It doesn't take long 
to have a repo up and running on your own machine.
Nov 03 2015
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Nov 03, 2015 at 11:06:57PM +0000, Chris via Digitalmars-d wrote:

 On Tuesday, 3 November 2015 at 19:42:58 UTC, Andrei Alexandrescu wrote:
 

I wrote this: http://wiki.dlang.org/Starting_as_a_Contributor, is it
what you need it to be? -- Andrei


 
 "Then, github detects the new code and offers assistance to create a
 pull request with just a couple of clicks."
 
 The problem is when your own branch is a few weeks/months old. Then
 you have to do some upstream/update etc. magic. It happened to me once
 or twice. It put me off a bit, although I only fixed typos and trivial
 stuff like that.


It's not that hard. The thing is, the best way is to ALWAYS make changes
in a topic branch, never on master. That way, you just pull upstream
into master and rebase your topic branch:

	git checkout -b my_bugfix

	git commit
	git checkout master
	git pull upstream master
	git checkout my_bugfix
	git rebase master

	git push -f origin



 It's not D, it's git(hub) that makes things complicated. It'd be good
 if you could just update your own branch on github (refork it or
 whatever) and then clone it onto your own machine. But it's not that
 straight forward.


[...]

I'm not sure I understand what's so non-straightforward about it. If you
always work in a topic branch, as I suggested above, it should be
relatively painless. It's when you make changes on master and then try
to sync with upstream, that things become very messy, very quickly.

Unless you're complaining about git itself, in which case my only
suggestion is that you have to take the time to learn the "concept"
behind git. It's very likely *not* what most people imagine when they
think of "version control", and it's pretty important that you
understand that when working with git, you have to think in terms of
"directed acyclic graph" rather than "version control" in the
traditional sense of the word. Trying to work with git with the wrong
mental model of what it actually does will inevitably land you in a
situation where you feel like you don't know how to fix it.


T

-- 
Life is complex. It consists of real and imaginary parts. -- YHL
Nov 03 2015
parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 4 November 2015 at 00:06:34 UTC, H. S. Teoh wrote:

 It's not that hard. The thing is, the best way is to ALWAYS 
 make changes in a topic branch, never on master. That way, you 
 just pull upstream into master and rebase your topic branch:

 	git checkout -b my_bugfix

 	git commit
 	git checkout master
 	git pull upstream master
 	git checkout my_bugfix
 	git rebase master

 	git push -f origin



 It's not D, it's git(hub) that makes things complicated. It'd 
 be good if you could just update your own branch on github 
 (refork it or whatever) and then clone it onto your own 
 machine. But it's not that straight forward.


 [...]

 I'm not sure I understand what's so non-straightforward about 
 it. If you always work in a topic branch, as I suggested above, 
 it should be relatively painless. It's when you make changes on 
 master and then try to sync with upstream, that things become 
 very messy, very quickly.


What I tried to do was to update my branch to the latest version 
of master and then send my humble fix back to my (updated) branch 
and up to master. The whole thing about "topic branch" and the 
array of commands that follow shows (me) that it is not straight 
forward. I have to look up/ask every time "Sorry, how do I do 
that again" - "rebase, upstream blah". Thing is, I expected 
github (not git) to be easier, like clicking on "Update branch", 
then

     git update
     git commit mychange.d

and then go to github and just click on "make PR". IMO, it's a 
waste of time to deal with all those commands (upstream blah) 
when you have a homepage like github. They should handle it. But 
that's just my opinion.

The base line is, it makes me think twice about changing 
something, especially when I could do it on the fly as in "Uh, 
there's something I could fix, wait ... Ah, no how do I do that 
again, uh, wait git upstream, no stop rebase ah f*ck! I'll do it 
tomorrow ..." (I won't)


 Unless you're complaining about git itself, in which case my 
 only suggestion is that you have to take the time to learn the 
 "concept" behind git. It's very likely *not* what most people 
 imagine when they think of "version control", and it's pretty 
 important that you understand that when working with git, you 
 have to think in terms of "directed acyclic graph" rather than 
 "version control" in the traditional sense of the word. Trying 
 to work with git with the wrong mental model of what it 
 actually does will inevitably land you in a situation where you 
 feel like you don't know how to fix it.


 T
Nov 03 2015
parent Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Wednesday, 4 November 2015 at 00:34:08 UTC, Chris wrote:

 What I tried to do was to update my branch to the latest 
 version of master and then send my humble fix back to my 
 (updated) branch and up to master. The whole thing about "topic 
 branch" and the array of commands that follow shows (me) that 
 it is not straight forward. I have to look up/ask every time 
 "Sorry, how do I do that again" - "rebase, upstream blah". 
 Thing is, I expected github (not git) to be easier, like 
 clicking on "Update branch", then


Keeping changes updated with master is not easy whether it is 
github or some other tool. If your branch and master both have 
changes you risk conflicts and those conflicts must be resolved.

If you have a fix for your branch, then fix it.

These are two separate operations and can be done independently 
of the other. If your branch can be merged cleanly then a rebase 
is not necessary; if it can't be merged cleanly you'll need to be 
in your dev environment. Having a UI do a rebase when it is clean 
for you might be nice, but it won't do you any good when real 
work is necessary (unless you want GitHub to be a full 
development environment).
Nov 05 2015
prev sibling parent John Colvin <john.loughran.colvin gmail.com> writes:
On Tuesday, 3 November 2015 at 23:06:58 UTC, Chris wrote:

 On Tuesday, 3 November 2015 at 19:42:58 UTC, Andrei 
 Alexandrescu wrote:


 I wrote this: http://wiki.dlang.org/Starting_as_a_Contributor, 
 is it what you need it to be? -- Andrei


 "Then, github detects the new code and offers assistance to 
 create a pull request with just a couple of clicks."

 The problem is when your own branch is a few weeks/months old. 
 Then you have to do some upstream/update etc. magic. It 
 happened to me once or twice. It put me off a bit, although I 
 only fixed typos and trivial stuff like that.

 It's not D, it's git(hub) that makes things complicated. It'd 
 be good if you could just update your own branch on github 
 (refork it or whatever) and then clone it onto your own 
 machine. But it's not that straight forward.

 PS Jeffery, the first steps are really easy. It doesn't take 
 long to have a repo up and running on your own machine.


I might have missed a few details in the push command (writing 
from my phone), but iirc git will explain what to do:

git clone <address of upstream>
cd <dest. folder>
git remote add <e.g. personal> <address of your fork>
git checkout -b <branch name for feature>
<your changes here>
git push <e.g. personal>

Then make a pull request on github

To get master up to date:
git checkout master
git pull

Then make a new branch as before.


Using your own master doesn't really make sense unless your 
actually trying to publically fork the project. Just treat your 
github fork as a collection of personal branches that live at a 
different URL, which is easily managed with git remotes.
Nov 04 2015
prev sibling parent reply Gerald Jansen <gjansen ownmail.net> writes:
On Tuesday, 3 November 2015 at 19:42:58 UTC, Andrei Alexandrescu 
wrote:

 I wrote this: http://wiki.dlang.org/Starting_as_a_Contributor, 
 is it what you need it to be? -- Andrei


Okay, so we have slight variations that cause confusion for 
newcomers like me:

Model A:
- directly clone upstream (becomes origin)
- create topic-branch; work; commit
- switch to master branch; pull --ff-only origin master
- switch to topic-branch; rebase from master branch
- create my fork in github and add remote myfork
- push to myfork

Model B: (recommended if you are planning to create PRs from the 
outset?)
- first create my fork in github
- clone my fork (becomes origin)
- create topic-branch; work; commit
- add remote upstream
- switch to master branch; pull --ff-only upstream master
- switch to topic-branch; rebase from master branch
- push to origin

Of course there are many possible workflows with git and github, 
but it would be helpful to beginners if the various D wiki pages 
(and advice on the forums) followed a consistent model.
Nov 06 2015
next sibling parent reply krzaq <dlangmailinglist krzaq.cc> writes:
On Friday, 6 November 2015 at 11:07:10 UTC, Gerald Jansen wrote:

 On Tuesday, 3 November 2015 at 19:42:58 UTC, Andrei 
 Alexandrescu wrote:

 I wrote this: http://wiki.dlang.org/Starting_as_a_Contributor, 
 is it what you need it to be? -- Andrei


 Okay, so we have slight variations that cause confusion for 
 newcomers like me:

 Model A:
 - directly clone upstream (becomes origin)
 - create topic-branch; work; commit
 - switch to master branch; pull --ff-only origin master
 - switch to topic-branch; rebase from master branch
 - create my fork in github and add remote myfork
 - push to myfork

 Model B: (recommended if you are planning to create PRs from 
 the outset?)
 - first create my fork in github
 - clone my fork (becomes origin)
 - create topic-branch; work; commit
 - add remote upstream
 - switch to master branch; pull --ff-only upstream master
 - switch to topic-branch; rebase from master branch
 - push to origin

 Of course there are many possible workflows with git and 
 github, but it would be helpful to beginners if the various D 
 wiki pages (and advice on the forums) followed a consistent 
 model.


Either way, just take a look how much of red tape is needed 
around >work<, when the opposite should be true: >work< should be 
the major part of any bugfixing.

Visually it is staggering - the first time I read your post, I 
thought you'd simply forgotten to mention actual coding: 
http://i.imgur.com/fuiSxwj.png
Nov 06 2015
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/6/2015 4:26 AM, krzaq wrote:

 Either way, just take a look how much of red tape is needed around >work<, when
 the opposite should be true: >work< should be the major part of any bugfixing.


Most of that is just setting things up initially. Once that is done, the 
incremental work for each PR is just a couple minutes.


 Visually it is staggering - the first time I read your post, I thought you'd
 simply forgotten to mention actual coding: http://i.imgur.com/fuiSxwj.png


It'd be nice if we could just fix code, but the project has too many people 
working on it and is too complex for that anymore.
Nov 06 2015
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/6/15 7:26 AM, krzaq wrote:

 Either way, just take a look how much of red tape is needed around
  >work<, when the opposite should be true: >work< should be the major
 part of any bugfixing.

 Visually it is staggering - the first time I read your post, I thought
 you'd simply forgotten to mention actual coding:
 http://i.imgur.com/fuiSxwj.png


It doesn't seem that bad to me. They are things you do once, and quite 
simple and common. We have a script called tools/update.sh that 
automates these steps, but teaching how to use and babysit that script 
would end up about as long winded.

That said, if you have idea just let us know!


Andrei
Nov 07 2015
prev sibling next sibling parent reply Chris <wendlec tcd.ie> writes:
On Friday, 6 November 2015 at 11:07:10 UTC, Gerald Jansen wrote:

 Okay, so we have slight variations that cause confusion for 
 newcomers like me:

 Model A:
 - directly clone upstream (becomes origin)
 - create topic-branch; work; commit
 - switch to master branch; pull --ff-only origin master
 - switch to topic-branch; rebase from master branch
 - create my fork in github and add remote myfork
 - push to myfork

 Model B: (recommended if you are planning to create PRs from 
 the outset?)
 - first create my fork in github
 - clone my fork (becomes origin)
 - create topic-branch; work; commit
 - add remote upstream
 - switch to master branch; pull --ff-only upstream master
 - switch to topic-branch; rebase from master branch
 - push to origin

 Of course there are many possible workflows with git and 
 github, but it would be helpful to beginners if the various D 
 wiki pages (and advice on the forums) followed a consistent 
 model.


Thanks for this post. There is some confusion, which makes people 
say "Naw, I dunno, maybe tomorrow." At least me!
Nov 06 2015
next sibling parent reply Gary Willoughby <dev nomad.so> writes:
On Friday, 6 November 2015 at 12:46:16 UTC, Chris wrote:

 Thanks for this post. There is some confusion, which makes 
 people say "Naw, I dunno, maybe tomorrow." At least me!


It's all in the wiki:

http://wiki.dlang.org/Pull_Requests
Nov 06 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/6/15 11:01 AM, Gary Willoughby wrote:

 On Friday, 6 November 2015 at 12:46:16 UTC, Chris wrote:

 Thanks for this post. There is some confusion, which makes people say
 "Naw, I dunno, maybe tomorrow." At least me!


 It's all in the wiki:

 http://wiki.dlang.org/Pull_Requests


I linked http://wiki.dlang.org/Pull_Requests and 
http://wiki.dlang.org/Starting_as_a_Contributor to one another. -- Andrei
Nov 07 2015
parent Chris <wendlec tcd.ie> writes:
On Saturday, 7 November 2015 at 17:45:52 UTC, Andrei Alexandrescu 
wrote:

 On 11/6/15 11:01 AM, Gary Willoughby wrote:

 On Friday, 6 November 2015 at 12:46:16 UTC, Chris wrote:

 Thanks for this post. There is some confusion, which makes 
 people say
 "Naw, I dunno, maybe tomorrow." At least me!


 It's all in the wiki:

 http://wiki.dlang.org/Pull_Requests


 I linked http://wiki.dlang.org/Pull_Requests and 
 http://wiki.dlang.org/Starting_as_a_Contributor to one another. 
 -- Andrei


Ok, so I will delete my current branch and start from scratch 
following the recommendations. Maybe it'll be easier for me to 
keep up to date with phobos and make more PRs. In my case it's 
just typos and easy stuff like that, but every little helps :)
Nov 07 2015
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/6/2015 4:46 AM, Chris wrote:

 Thanks for this post. There is some confusion, which makes people say "Naw, I
 dunno, maybe tomorrow." At least me!


If you want, you can simply post a patch to bugzilla, which will then wait for 
someone to turn it into a PR.
Nov 06 2015
prev sibling parent Sebastiaan Koppe <mail skoppe.eu> writes:
On Friday, 6 November 2015 at 11:07:10 UTC, Gerald Jansen wrote:

 Model A:

 Model B: (recommended if you are planning to create PRs from 
 the outset?)


Go with Model B, it gets the origin/upstream naming right. 
Besides that, potatoes potatoes.


 Of course there are many possible workflows with git and 
 github, but it would be helpful to beginners if the various D 
 wiki pages (and advice on the forums) followed a consistent 
 model.


If its open source its on github, if its on github people use 
pull-requests. How many ways are there to do pull request?
Nov 06 2015
prev sibling next sibling parent Sebastiaan Koppe <mail skoppe.eu> writes:
On Tuesday, 3 November 2015 at 14:35:08 UTC, Andrei Alexandrescu 
wrote:

 https://goo.gl/r24Izw

 Some of them are D1 only; I'll make an executive decision about 
 those soon. Some of them have been fixed or obviated by recent 
 improvements. And finally the bulk of them need a little work 
 each to get them fixed.

 I'm thinking this has crowdsourcing written all over it. It 
 would be great if many of us made one pass through the list and 
 take a look at bugs with an eye for cleaning up the list.


 Andrei


I skimmed through the list, looking for easy starters. This is 
what in the end held me back:

- comment saying how a bug-fix will break code
- unfinished discussion about how its not a bug, (or how to solve 
it, e.g. https://issues.dlang.org/show_bug.cgi?id=14485)
- halfway fixes and no clear path how to fix the other half (e.g. 
https://issues.dlang.org/show_bug.cgi?id=4391, curry was renamed 
to partial to avoid confusion. Now do we still want curry?)
- unclear goals (e.g. 
https://issues.dlang.org/show_bug.cgi?id=4656 `Let's keep it 
opened until the error message is fixed.`)

I do not know what to do with that stuff. In most cases I figure 
they require an executive decision.

What I can do is go through the list and recommend bugs to be 
closed/wontfix.
Nov 05 2015
prev sibling next sibling parent reply BBaz <2b.temp gmx.com> writes:
On Tuesday, 3 November 2015 at 14:35:08 UTC, Andrei Alexandrescu 
wrote:

 https://goo.gl/r24Izw

 Some of them are D1 only; I'll make an executive decision about 
 those soon. Some of them have been fixed or obviated by recent 
 improvements. And finally the bulk of them need a little work 
 each to get them fixed.

 I'm thinking this has crowdsourcing written all over it. It 
 would be great if many of us made one pass through the list and 
 take a look at bugs with an eye for cleaning up the list.


 Andrei


Hello, I've reviewed the list and found a subset of 30 bugs that 
I've closed because whatever is my position it was clear that 
they are fixed now or invalid.

However, I've spotted "bearophile". He has opened a lot of issues 
just because he wanted this or that in std.range. I think that 
most of his issues could be closed because he should rather 
discuss on the NG or even propose an implementation on GH...

So I don't know...and I ask, should the garbages from bearophile 
be closed ?
Dec 01 2015
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/1/15 9:17 AM, BBaz wrote:

 On Tuesday, 3 November 2015 at 14:35:08 UTC, Andrei Alexandrescu wrote:

 https://goo.gl/r24Izw

 Some of them are D1 only; I'll make an executive decision about those
 soon. Some of them have been fixed or obviated by recent improvements.
 And finally the bulk of them need a little work each to get them fixed.

 I'm thinking this has crowdsourcing written all over it. It would be
 great if many of us made one pass through the list and take a look at
 bugs with an eye for cleaning up the list.


 Andrei


 Hello, I've reviewed the list and found a subset of 30 bugs that I've
 closed because whatever is my position it was clear that they are fixed
 now or invalid.

 However, I've spotted "bearophile". He has opened a lot of issues just
 because he wanted this or that in std.range. I think that most of his
 issues could be closed because he should rather discuss on the NG or
 even propose an implementation on GH...

 So I don't know...and I ask, should the garbages from bearophile be
 closed ?


Please list links to those here, and thanks for all your work! -- Andrei
Dec 01 2015
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 12/1/15 9:17 AM, BBaz wrote:


 However, I've spotted "bearophile". He has opened a lot of issues just
 because he wanted this or that in std.range. I think that most of his
 issues could be closed because he should rather discuss on the NG or
 even propose an implementation on GH...


Open enhancements should be left alone IMO. Unless it has been decided 
that there is zero possibility for them being implemented, they are just 
waiting for someone to do it.

Enhancements also shouldn't count towards any open "bug" count.

-Steve
Dec 01 2015
parent reply BBaz <2b.temp gmx.com> writes:
On Tuesday, 1 December 2015 at 14:50:24 UTC, Steven Schveighoffer 
wrote:

 On 12/1/15 9:17 AM, BBaz wrote:


 However, I've spotted "bearophile". He has opened a lot of 
 issues just
 because he wanted this or that in std.range. I think that most 
 of his
 issues could be closed because he should rather discuss on the 
 NG or
 even propose an implementation on GH...


 Open enhancements should be left alone IMO. Unless it has been 
 decided that there is zero possibility for them being 
 implemented, they are just waiting for someone to do it.

 Enhancements also shouldn't count towards any open "bug" count.

 -Steve


I understand, but there are much...not 3 or 4 , more something 
like 20...
Anyway, message get, i'll post the list tomorrow.
Dec 01 2015
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 12/1/15 9:56 AM, BBaz wrote:

 On Tuesday, 1 December 2015 at 14:50:24 UTC, Steven Schveighoffer wrote:

 On 12/1/15 9:17 AM, BBaz wrote:


 However, I've spotted "bearophile". He has opened a lot of issues just
 because he wanted this or that in std.range. I think that most of his
 issues could be closed because he should rather discuss on the NG or
 even propose an implementation on GH...


 Open enhancements should be left alone IMO. Unless it has been decided
 that there is zero possibility for them being implemented, they are
 just waiting for someone to do it.

 Enhancements also shouldn't count towards any open "bug" count.


 I understand, but there are much...not 3 or 4 , more something like 20...
 Anyway, message get, i'll post the list tomorrow.


Yeah, bearophile is like that, he has a lot of ideas ;)

Some of them have been implemented, after sitting for a long time. So I 
don't think it's correct to close them. I'm all for closing ones that 
absolutely won't be implemented though.

-Steve
Dec 01 2015
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
BBaz:


 So I don't know...and I ask, should the garbages from 
 bearophile be closed ?


Hello, I use D every day, and there are several functions that 
I'd like in Phobos. I think all/most of them can be of general 
usefulness. While I am often wrong, those ERs come from plenty of 
experience coding in D and other languages, so throwing them away 
*en masse* is unwise. They should be judged singularly.

Bye,
bearophile
Dec 02 2015
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 12/01/2015 03:17 PM, BBaz wrote:

 So I don't know...and I ask, should the garbages from bearophile be
 closed ?


This is a loaded question.
Dec 03 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/03/2015 09:35 AM, Andrei Alexandrescu wrote:

 https://goo.gl/r24Izw

 Some of them are D1 only; I'll make an executive decision about those
 soon. Some of them have been fixed or obviated by recent improvements.
 And finally the bulk of them need a little work each to get them fixed.

 I'm thinking this has crowdsourcing written all over it. It would be
 great if many of us made one pass through the list and take a look at
 bugs with an eye for cleaning up the list.


Replying to my own message from November 2015... well, right now we have 
953 open bugs for Phobos. 500 is next! -- Andrei
Dec 24 2016
parent Brad Roberts via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 12/24/2016 7:24 AM, Andrei Alexandrescu via Digitalmars-d wrote:

 On 11/03/2015 09:35 AM, Andrei Alexandrescu wrote:

 https://goo.gl/r24Izw


 Replying to my own message from November 2015... well, right now we 
 have 953 open bugs for Phobos. 500 is next! -- Andrei


Progress is progress, but I prefer looking at more targeted lists than 
all open bugs.  My favorite is all open bugs with severity above normal 
(which is the default for new bugs).  That trend, unfortunately, is 
generally upwards and always has been.  Here's my saved search, which I 
just made public:

https://issues.dlang.org/buglist.cgi?cmdtype=runnamed&list_id=212617&namedcmd=high%20severity

There's more open regressions than ever before too.

My 2 cents,
Brad
Dec 24 2016