www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Help me understand how to contribute to bugs report / fixing

reply Fra Mecca <me francescomecca.eu> writes:
Hi,
I have been lurking in the bug tracker for some time, checking 
and trying to reproduce bugs and fixes.

I finally want to submit something and contribute but I am having 
an hard time understanding the workflow.

Pull request are done via git and bugs reported by the tracker.
The problem is when I want to understand if the bug of the 
tracker is referenced in the repo of the organization and has an 
open PR.

---

Real world case:
this bug has been reported recently:
https://issues.dlang.org/show_bug.cgi?id=18288#add_comment

but it should be closed given how in the recent changes to the 
phobos master branch the bug is fixed. You can double check that 
by running the code snippet using dmd-nightly in run.dlang.io.

 From a quick glance at the phobos repo, I found no mention of 

on the same file (comparison.d) that probably fixed the issue for 
bug 18288.

What should I do now?
I am undecided between:
- commenting on the bug tracker and close the bug
- link the pr 6056 on the bug tracker
- leaving it be

I feel that the section "Get involved" on the D wiki should aid 
newcomers with a more detailed description of the workflow of 
maintainers and collaborators.
Jan 26 2018
next sibling parent Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On Friday, 26 January 2018 at 20:43:05 UTC, Fra Mecca wrote:
 What should I do now?
 I am undecided between:
 - commenting on the bug tracker and close the bug
 - link the pr 6056 on the bug tracker
 - leaving it be
Leaving a comment on the bug with a link to the PR, and marking the bug resolved fixed is exactly what you should do, and thank you. :) -- Simen
Jan 26 2018
prev sibling next sibling parent ag0aep6g <anonymous example.com> writes:
On 01/26/2018 09:43 PM, Fra Mecca wrote:
 Real world case:
 this bug has been reported recently:
 https://issues.dlang.org/show_bug.cgi?id=18288#add_comment
[...]
  From a quick glance at the phobos repo, I found no mention of this bug 

 (comparison.d) that probably fixed the issue for bug 18288.
by dlang-bot. The check marks in the "auto-close" column indicate that the issues should have been closed when the PR was merged. But apparently only the first one was actually closed. This might be a bug in dlang-bot. I've filed an issue on the bot: https://github.com/dlang-bots/dlang-bot/issues/175
 What should I do now?
 I am undecided between:
 - commenting on the bug tracker and close the bug
 - link the pr 6056 on the bug tracker
 - leaving it be
When you can point to the PR that fixed an issue, close the issue as RESOLVED FIXED and leave a comment pointing to the PR. Something along the lines of "Fixed by https://github.com/dlang/phobos/pull/6056". When you don't know what fixed an issue, you can close as RESOLVED WORKSFORME. But make sure that you've taken all the necessary steps to reproduce the issue: operating system, compiler flags, etc. In both cases, it's great when you can make a PR that adds a test to the the tests (as far as I see), so that's not needed here.
Jan 26 2018
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jan 26, 2018 at 08:43:05PM +0000, Fra Mecca via Digitalmars-d-learn
wrote:
[...]
 Pull request are done via git and bugs reported by the tracker.  The
 problem is when I want to understand if the bug of the tracker is
 referenced in the repo of the organization and has an open PR.
The way it's done is that in your git commit, include a commit message like this: Fix issue 12345: <summary description here> This will cause the bot on github to automatically link the PR to the bugzilla issue, so when the PR gets merged, the bug will be updated. On the bugzilla side, the convention is that once there's a PR for that bug, you post the github link in a bugnote and add "pull" to the list of keywords. This way people can find the PR from the bug or vice versa. [...]
 I feel that the section "Get involved" on the D wiki should aid
 newcomers with a more detailed description of the workflow of
 maintainers and collaborators.
Now that you know how, perhaps you should update that page so that it's more helpful to newcomers. That's what a wiki is for. ;-) We could do it too, but it might be better if you did it since you still have the fresh outlook of a newcomer, whereas old-timers like us would probably be unconsciously making assumptions that newcomers have no idea about, and wind up writing something that isn't as helpful as it could be. T -- Always remember that you are unique. Just like everybody else. -- despair.com
Jan 26 2018