Hello.

there are some c-style array declarations both in druntime and in phobos. i made two patches that fixes 'em:

https://issues.dlang.org/show_bug.cgi?id=13401 https://issues.dlang.org/show_bug.cgi?id=13402

On Saturday, 30 August 2014 at 10:57:51 UTC, ketmar via Digitalmars-d wrote:
> Hello.
>
> there are some c-style array declarations both in druntime and in
> phobos. i made two patches that fixes 'em:
>
> https://issues.dlang.org/show_bug.cgi?id=13401
> https://issues.dlang.org/show_bug.cgi?id=13402

If you want to contribute, please create pull requests on github:

https://github.com/D-Programming-Language

It's doubtful that anyone is going to take your patches and create PR's for you. So, creating patches and adding them to bugzilla isn't particularly useful, even if it's good code.

- Jonathan M Davis

On Sat, 30 Aug 2014 11:31:13 +0000
Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> If you want to contribute, please create pull requests on github:
sorry, i'm not using github and not planning to register on github either. i have a personal reason for it.

> It's doubtful that anyone is going to take your patches and create PR's for you. So, creating patches and adding them to bugzilla isn't particularly useful, even if it's good code.
so bugzilla should be closed then. i already told that before: there is no sense in reporting anything to bugzilla: it will rot there forever. unless the author makes the post in D NG -- just to be told that bugzilla is not a place to put patches.

that's why i rarely adding anything "big" to bugzilla. i don't mind to support my patches on my own though -- my dmd and gdc are heavily patched already, two more patches doesn't make any difference.

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

> sorry, i'm not using github and not planning to register on github
> either. i have a personal reason for it.

That's your choice, but if you want to contribute patches to the compiler or libraries you will need to get over it and make an account.

> so bugzilla should be closed then. i already told that before: there is
> no sense in reporting anything to bugzilla: it will rot there forever.
> unless the author makes the post in D NG -- just to be told that
> bugzilla is not a place to put patches.

Bugzilla is for bug reports, github is for patches.  You're correct that there is little point in posting patches to bugzilla, or to the newsgroup. 

On Sat, 30 Aug 2014 22:25:18 +1000
Daniel Murphy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> That's your choice, but if you want to contribute patches to the compiler or libraries you will need to get over it and make an account.
not *that* much. ok, i got the point and will not make noise about this anymore.

On 30 Aug 2014 12:35, "Jonathan M Davis via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> On Saturday, 30 August 2014 at 10:57:51 UTC, ketmar via Digitalmars-d
wrote:
>>
>> Hello.
>>
>> there are some c-style array declarations both in druntime and in phobos. i made two patches that fixes 'em:
>>
>>https://issues.dlang.org/show_bug.cgi?id=13401 https://issues.dlang.org/show_bug.cgi?id=13402
>
>
> If you want to contribute, please create pull requests on github:
>
>https://github.com/D-Programming-Language
>
> It's doubtful that anyone is going to take your patches and create PR's
for you. So, creating patches and adding them to bugzilla isn't particularly useful, even if it's good code.
>
> - Jonathan M Davis

Responses like this aren't particularly useful either.  We have a 'patch' keyword in bugzilla (from memory), and people are free to use that as a tool to manage bugs raised against D.

In fact, has anyone recently gone through bug tickets with attachments and checked for patches?  This could be one thing to do for EMSI's monthly bug squashing event (a similar thing is already done for squashing regressions or ICE's in the beta releases).

It doesn't take a lot of work to do this.

- Find and appropriately tag any bug reports with patches attached.
- Review the tagged bug reports.
- Mark as 'needs-work' if the patch doesn't apply.
- Mark as 'pull-request' and raise a PR if it applies and fixes the
bug/enhancement.  Use your best judgement when reviewing the code, but
after a PR has been created, it will be properly code reviewed.
- Close if the report is no longer reproducible, or patch has been applied
or rejected (rejected enhancement patch).

And doing that for a couple hours a month is better than telling people not to send patches to bugzilla because no one will look at it.

If you put this doubt in people's minds, what does that say about the actual bug reports?  Should I even bother raising a bug report when no one will look at it?  Maybe I should just instead raise a PR with a test case and a comment next to the line that ICE's.  People read PRs, so my bug will be tended to answer fixed sooner.

(I don't actually plan in doing this).

Iain.

"Iain Buclaw via Digitalmars-d" <digitalmars-d@puremagic.com> wrote in message news:mailman.107.1409402768.5783.digitalmars-d@puremagic.com...

> Responses like this aren't particularly useful either.  We have a 'patch' keyword in bugzilla
> (from memory), and people are free to use that as a tool to manage bugs raised against D.

The patch keyword is (as I'm sure you know) from the pre-github days when contribution was done with bugzilla.  This system did not work well.

> In fact, has anyone recently gone through bug tickets with attachments and checked for
> patches?  This could be one thing to do for EMSI's monthly bug squashing event (a similar
> thing is already done for squashing regressions or ICE's in the beta releases).

It would be useful if someone did this, but presenting somebody else's patch on github is not ideal.  The original author is usually in the best position to update and defend the patch.

> It doesn't take a lot of work to do this.

It doesn't take a lot of work to open a pull request.

> - Find and appropriately tag any bug reports with patches attached.
> - Review the tagged bug reports.
> - Mark as 'needs-work' if the patch doesn't apply.
> - Mark as 'pull-request' and raise a PR if it applies and fixes the bug/enhancement.  Use your
> best judgement when reviewing the code, but after a PR has been created, it will be properly
> code reviewed.
> - Close if the report is no longer reproducible, or patch has been applied or rejected (rejected
> enhancement patch).

This is exactly the same as the normal procedure of inspecting a bugzilla issue, except with the added step of checking if an existing patch fixes the issue.  I assume people are already doing this.

> And doing that for a couple hours a month is better than telling people not to send patches to
> bugzilla because no one will look at it.

It's wasted work over the original author just making a pull request.  If you're gone to the effort to fix something, you might as well follow through with it.

> If you put this doubt in people's minds, what does that say about the actual bug reports?  Should
> I even bother raising a bug report when no one will look at it?  Maybe I should just instead raise
> a PR with a test case and a comment next to the line that ICE's.  People read PRs, so my bug
> will be tended to answer fixed sooner.

Making a pull request is certainly a good way to get attention for a bug you care about.  Although you will be told to file it in bugzilla either way. 

I agree with Iain, we should respect opinion of people trying to stay away from intrusive ecosystems like GitHub. While probability of someone picking the patches and proceeding with them is low (and we shouldn't give false hopes) there is no place for "GitHub or GTFO" reaction. It is just rude.

On 30 Aug 2014 14:05, "Daniel Murphy via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> "Iain Buclaw via Digitalmars-d" <digitalmars-d@puremagic.com> wrote in
message news:mailman.107.1409402768.5783.digitalmars-d@puremagic.com...
>
>
>> Responses like this aren't particularly useful either.  We have a
'patch' keyword in bugzilla
>> (from memory), and people are free to use that as a tool to manage bugs
raised against D.
>
>
> The patch keyword is (as I'm sure you know) from the pre-github days when
contribution was done with bugzilla.  This system did not work well.
>

Every time I submitted a patch to bugzilla, it was in the next release. I can't say I share this view.

It's like having a meeting on IRC vs. Skype.  Both get the job done, but those on Skype think that IRC is so arcane.

>> In fact, has anyone recently gone through bug tickets with attachments
and checked for
>> patches?  This could be one thing to do for EMSI's monthly bug squashing
event (a similar
>> thing is already done for squashing regressions or ICE's in the beta
releases).
>
>
> It would be useful if someone did this, but presenting somebody else's
patch on github is not ideal.  The original author is usually in the best position to update and defend the patch.
>

If the fix can be done better, someone can raise a new PR (Kenji and Walter occasionally do this), closing the original.

As for defending. I don't think we should worry about that.  Patches on bugzilla should be taken with salt.

>> It doesn't take a lot of work to do this.
>
>
> It doesn't take a lot of work to open a pull request.
>

In that case, there's no reason why you shouldn't raise the PR for the original author then.  :o)

Iain.

On Sat, Aug 30, 2014 at 01:40:49PM +0000, Dicebot via Digitalmars-d wrote:
> I agree with Iain, we should respect opinion of people trying to stay away from intrusive ecosystems like GitHub. While probability of someone picking the patches and proceeding with them is low (and we shouldn't give false hopes) there is no place for "GitHub or GTFO" reaction. It is just rude.

I can't believe you people would waste hours on a useless discussion, when it takes just 5 minutes to generate PR's from the OP's patches:

	https://github.com/D-Programming-Language/druntime/pull/939
	https://github.com/D-Programming-Language/phobos/pull/2475

Seriously, we forum people need to get a perspective sometimes. *grumble* *grumble*


T

-- 
Those who don't understand Unix are condemned to reinvent it, poorly.