Add minimal information with a new issue?
Hi, What do you think if we suggest a "template" for the new bugs? For example: * Python version (exact version) * Operating System * on Linux -> Distribution (python can have some patches) * Add a script for the reproduction of the bug * Eventually, try with the docker images (on i386,x86_64, ...) * etc... We can lost a lot of time just trying to find the right information for the reproduction of the issue. Cheers, Stéphane -- Stéphane Wirtel - https://wirtel.be - @matrixise
On Feb 21, 2019, at 06:53, Stephane Wirtel <stephane@wirtel.be> wrote:
What do you think if we suggest a "template" for the new bugs?
For example: * Python version (exact version) * Operating System * on Linux -> Distribution (python can have some patches) * Add a script for the reproduction of the bug * Eventually, try with the docker images (on i386,x86_64, ...) * etc...
We can lost a lot of time just trying to find the right information for the reproduction of the issue.
Getting reproducible cases is usually the hardest part of any bug fix. :) If there is information about the platform, version of Python, build flags etc. that we want to capture in bug reports, there should be a `python -m bugreport` or some such that we can ask people to run and attach or paste into their issue. Maybe even cooler would be something that opens a new GitHub issue with that information pre-populated. -Barry
Hi, I wrote "python -m test.pythoninfo", but I wrote it to debug buildbot failures. It produces a large output. Only very few info are useful, but previously it was hard to get these info. I wouldn't suggest to start to request it. Or if you want it, it should be attached as a file to not pollute the issue. Note: On Fedora at least, you have to install python3-test package to get test.pythoninfo. Victor Le jeu. 21 févr. 2019 à 19:11, Barry Warsaw <barry@python.org> a écrit :
On Feb 21, 2019, at 06:53, Stephane Wirtel <stephane@wirtel.be> wrote:
What do you think if we suggest a "template" for the new bugs?
For example: * Python version (exact version) * Operating System * on Linux -> Distribution (python can have some patches) * Add a script for the reproduction of the bug * Eventually, try with the docker images (on i386,x86_64, ...) * etc...
We can lost a lot of time just trying to find the right information for the reproduction of the issue.
Getting reproducible cases is usually the hardest part of any bug fix. :)
If there is information about the platform, version of Python, build flags etc. that we want to capture in bug reports, there should be a `python -m bugreport` or some such that we can ask people to run and attach or paste into their issue. Maybe even cooler would be something that opens a new GitHub issue with that information pre-populated.
-Barry
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/vstinner%40redhat.com
-- Night gathers, and now my watch begins. It shall not end until my death.
On Feb 21, 2019, at 6:53 AM, Stephane Wirtel <stephane@wirtel.be> wrote:
What do you think if we suggest a "template" for the new bugs?
99% of the time the template would be not applicable. Historically, we asked for more information when needed and that wasn't very often. I think that anything that raises the cost of filing a bug report will work to our detriment. Ideally, we want the barriers to reporting to be as low as possible. Raymond
On Feb 21, 2019, at 10:34, Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
I think that anything that raises the cost of filing a bug report will work to our detriment. Ideally, we want the barriers to reporting to be as low as possible.
`python -m reportbug` could make the process even easier (too easy?). -Barry
On 21Feb2019 1117, Barry Warsaw wrote:
On Feb 21, 2019, at 10:34, Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
I think that anything that raises the cost of filing a bug report will work to our detriment. Ideally, we want the barriers to reporting to be as low as possible.
`python -m reportbug` could make the process even easier (too easy?).
It's spelled `python -m reportabug` ;) https://pypi.org/project/reportabug/ https://github.com/zooba/reportabug Example: https://github.com/zooba/reportabug/issues/1 Cheers, Steve
+1
Le 21 févr. 2019 à 21:06, Steve Dower <steve.dower@python.org> a écrit :
On 21Feb2019 1117, Barry Warsaw wrote:
On Feb 21, 2019, at 10:34, Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
I think that anything that raises the cost of filing a bug report will work to our detriment. Ideally, we want the barriers to reporting to be as low as possible. `python -m reportbug` could make the process even easier (too easy?).
It's spelled `python -m reportabug` ;)
https://pypi.org/project/reportabug/ https://github.com/zooba/reportabug
Example: https://github.com/zooba/reportabug/issues/1
Cheers, Steve _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/stephane%40wirtel.be
Barry Warsaw writes:
On Feb 21, 2019, at 10:34, Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
I think that anything that raises the cost of filing a bug report will work to our detriment. Ideally, we want the barriers to reporting to be as low as possible.
A template is probably counterproductive. A program that fills in the most of the template automatically would make the barrier lower than it currently is.
`python -m reportbug` could make the process even easier (too easy?).
If badly designed it could make the process too easy (ie, fill the tracker with reports that triage to "closed as duplicate of #NNNNN"). We know a lot about this process now, though. For example, Launchpad and some other trackers ask you to input some keywords and tries to pull up related reports. The reportbug program could collect internal information (with an option it could suck up all the information Victor's program collects), ask the reporter a few simple questions, formulate the query (including both the generated information and the reporter's information), and open a browser window on the tracker. This would probably make a good GSoC project .... Steve -- Associate Professor Division of Policy and Planning Science http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnbull@sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN
participants (6)
-
Barry Warsaw -
Raymond Hettinger -
Stephane Wirtel -
Stephen J. Turnbull -
Steve Dower -
Victor Stinner