Re: Under 1000 opened bugs for Phobos
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_id=212617=high%20severity There's more open regressions than ever before too. My 2 cents, Brad
Re: Under 1000 opened bugs for Phobos
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
Re: Under 1000 opened bugs for Phobos
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.
Re: Under 1000 opened bugs for Phobos
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
Re: Under 1000 opened bugs for Phobos
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
Re: Under 1000 opened bugs for Phobos
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
Re: Under 1000 opened bugs for Phobos
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.
Re: Under 1000 opened bugs for Phobos
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
Re: Under 1000 opened bugs for Phobos
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 ?
Re: Under 1000 opened bugs for Phobos
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
Re: Under 1000 opened bugs for Phobos
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 :)
Re: Under 1000 opened bugs for Phobos
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
Re: Under 1000 opened bugs for Phobos
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.
Re: Under 1000 opened bugs for Phobos
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?
Re: Under 1000 opened bugs for Phobos
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
Re: Under 1000 opened bugs for Phobos
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
Re: Under 1000 opened bugs for Phobos
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!
Re: Under 1000 opened bugs for Phobos
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.
Re: Under 1000 opened bugs for Phobos
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.
Re: Under 1000 opened bugs for Phobos
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).
Re: Under 1000 opened bugs for Phobos
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.
Re: Under 1000 opened bugs for Phobos
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 cd git remote add git checkout -b git push 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.
Re: Under 1000 opened bugs for Phobos
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
Re: Under 1000 opened bugs for Phobos
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!)
Re: Under 1000 opened bugs for Phobos
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.
Re: Under 1000 opened bugs for Phobos
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
Re: Under 1000 opened bugs for Phobos
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)
Re: Under 1000 opened bugs for Phobos
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
Re: Under 1000 opened bugs for Phobos
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 ... # make edits here git commit git checkout master git pull upstream master git checkout my_bugfix git rebase master # Now your fixes are updated. 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
Re: Under 1000 opened bugs for Phobos
On Tue, Nov 03, 2015 at 11:06:57PM +, 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 ... # make edits here git commit git checkout master git pull upstream master git checkout my_bugfix git rebase master # Now your fixes are updated. 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
Under 1000 opened bugs for Phobos
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
