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

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

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!)

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

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)

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

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.

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
	... # 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

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

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.