"ketmar via Digitalmars-d"  wrote in message news:mailman.120.1409408631.5783.digitalmars-d@puremagic.com...

> 'cause i don't want to be a part of github. i'd better eat dirt.

It's a shame that your dislike of github is stronger than your desire to contribute code. 

On Saturday, 30 August 2014 at 14:38:10 UTC, Daniel Murphy wrote:
> "ketmar via Digitalmars-d"  wrote in message news:mailman.120.1409408631.5783.digitalmars-d@puremagic.com...
>
>> 'cause i don't want to be a part of github. i'd better eat dirt.
>
> It's a shame that your dislike of github is stronger than your desire to contribute code.

It is a shame that your desire to act smart is stronger than your desire to accept contributions.

On Saturday, 30 August 2014 at 14:35:52 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 30 August 2014 at 14:32:01 UTC, Daniel Murphy wrote:
>> Using github is similar to our requirement to match the code style when submitting patches.  It's non-negotiable, because there's no good reason not to do it.  You just remove those tabs, then get on with it.
>
> Here is a good reason: «I have no interest in learning github, and I personally don't care if you accept this patch, but here you have it in case you want to improve your system».
>
> Here is another good reason: «Figuring out the D process is waaaay down on my todo list, maybe sometime next month, next year, next…»

I'm fine with people submitting patches in bugzilla, but they need to realize it's not the procedure.

So it's "welcome help", but there's still the actual work that needs to be done by someone else: Not only the pull, but the review, sticking with the review, etc...

I can also appreciate that filing a bug is work in itself. Doing that is already a step most people don't take. We just need to meet halfway, and not bitch about it: Both sides have or will provide work, and need to realize that about the other.

On Sun, 31 Aug 2014 00:32:06 +1000
Daniel Murphy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

or just not submitting patches. keep complaining about "alot of people speaking but not writing the code". good luck with it but i'm off. i'm perfectly comfortable with supporting patches by myself and applying 'em to my local builds.

On Saturday, 30 August 2014 at 14:37:54 UTC, Daniel Murphy wrote:
> If it takes longer to work out how to submit a pull request than make your patch, your patch probably wasn't worth doing.

I don't see any reasonable argument to support this view. A critical patch can be very small.
Telling contributors what is worthwhile and fun for them is kinda pointless.

Besides, if you maintain your own fork you might run into bugs that you have fixed that you don't know how will interact with the main branch. Letting someone else who know the main branch do the final patch based on what you have figured out is a nice gesture.

"Dicebot"  wrote in message news:hvwtyelwvrsrgvbcqsse@forum.dlang.org...

> No it is not. GitHub is an intrusive closed ecosystem and it is legitimate concern for anyone caring about the open internet. The fact that I have considered D contribution more important than this concern and the fact that you consider such reasoning silly does not make it less legit and/or widespread.

Making a throwaway github account does not endorse github any more than contributing to D another way does. 

On Saturday, 30 August 2014 at 14:46:50 UTC, ketmar via Digitalmars-d wrote:
> i'm
> perfectly comfortable with supporting patches by myself and applying
> 'em to my local builds.

I hope you keep making your patches available online. I am interested in your patches that fix the syntax issues that D suffer from. I am sure others are too.

On Sun, 31 Aug 2014 00:38:16 +1000
Daniel Murphy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> It's a shame that your dislike of github is stronger than your desire to contribute code.
i wasn't signed any agreements about "i have to eat github if i want make D better". i was thinking that having "attach" link is bugzilla means that i can attach my patch there and someone will look at it eventually. to make this process faster i announced my patch here ('cause i understand that most people using github and can just plainly miss bugzilla entry).

yet the first answers i got were "github or GTFO!" note that i wasn't wrote a single word about "take this patches or they will rot in bugzilla forever" in my original message. just plain info for those who interested. ok, i got the point: either "go github" or don't contribute. i chosing "don't contribute" in this case.

not that i'll stop to fill bugs or something. i will just not try to provide any fixes/enhancements anymore, even if i did that in my local copy. only plain "i found the bug, here is testcase" and "it would be good if compiler/druntime/phobos will do this".

On Sat, 30 Aug 2014 14:50:58 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> I hope you keep making your patches available online. I am interested in your patches that fix the syntax issues that D suffer from. I am sure others are too.
i'm planning to make website with my patches that fixes those "cosmetic issues" that can't find their way in mainline. using vibe.d, of course. ;-) i'll publish my build scripts and patchsets on the site and will keep the site up-to-date. one will be able to choose only the patches he want.

i'll announce it in 'D.announces' when it will be ready. so don't fear, no interested person will loose that. ;-)

"Ola Fosheim Grøstad" " wrote in message news:imcohxrhmfpkgjbtmspw@forum.dlang.org...

> I don't see any reasonable argument to support this view. A critical patch can be very small.

It's an exaggeration, but still usually true.  Most patches take some non-trivial work to create and debug, no matter how many lines they end up touching.  A patch that only takes a couple of seconds to create does not save much time for the person who is going to turn it into a pull request.

> Telling contributors what is worthwhile and fun for them is kinda pointless.

People can do what they wish.  But the best way to contribute is to follow the contribution process.

> Besides, if you maintain your own fork you might run into bugs that you have fixed that you don't know how will interact with the main branch. Letting someone else who know the main branch do the final patch based on what you have figured out is a nice gesture.

I suppose.