code cleanup in druntime and phobos

[Daniel Murphy via Digitalmars-d]

"Iain Buclaw via Digitalmars-d" <digitalmars-d at puremagic.com> wrote in 
message news:mailman.107.1409402768.5783.digitalmars-d at 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.