digitalmars.D.learn - Help me understand how to contribute to bugs report / fixing
- Fra Mecca (28/28) Jan 26 2018 Hi,
- Simen =?UTF-8?B?S2rDpnLDpXM=?= (6/11) Jan 26 2018 Leaving a comment on the bug with a link to the PR, and marking
- ag0aep6g (18/29) Jan 26 2018 The issue is actually referenced on the page of PR #6056, in the comment...
- H. S. Teoh (21/27) Jan 26 2018 The way it's done is that in your git commit, include a commit message
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
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 beLeaving 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
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/175What 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 beWhen 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
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