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

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.

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.

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

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!

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?

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

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.

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.

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