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