Re: [Python-Dev] checklist for filing a bug
Brett #. Gather important information Brett Info such as Python version, operating system version, etc.; Brett anything that might have influenced the code that lead to the Brett bug. I'd change this to something more explicit: # Gather important information * Python version * Operating system and version * Third-party modules installed/involved * Presence of user-written extension modules ... add your own faves here ... I doubt that a wet-behind-the-ears Python programmer who only knows Windows is likely to understand that Windows XP Home Edition (vs. CentOS 4) might be a factor in the emergence of the bug. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] checklist for filing a bug
In order to lower the barrier for reporting bugs, writing patches, and handling CVS commits, I am writing up checklists for each and I will put them up on python.org. -0 on the checklists. I don't think existing barriers are high at all. The entries may be variously regarded as codifying common sense or listing nice-to-haves instead of must haves. Based on the SF activity over the last few years, I conclude that the checklists attempt to solve a non-problem (or rather a very minor irritant). Yes, it would be great if everyone searched SF for all previous related bug reports, and spent time isolating/reproducing the cause, and if all bug reports were reproducible 100% of the time, and if someone wrote a unittest for it. Heck, it would be nicer still if they debugged the exact problem and fixed it ;-) However, in real life, we get plenty of useful reports that don't fit one or all of those criteria. I don't want to unnecessarily raise the bar and not have someone report a potentially valid bug. IMO, the proposal is administrivia that doesn't add value and possibly makes things worse (by causing some folks to not go through the hassle of filing a report). Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] checklist for filing a bug
Raymond Hettinger [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] In order to lower the barrier for reporting bugs, writing patches, and handling CVS commits, I am writing up checklists for each and I will put them up on python.org. -0 on the checklists. I am more enthusiastic about the idea of improving python.com's guidelines in this area, with some of Raymond's comments, and mine below, taken into consideration. To start with, I think the Developers page should have Bug Submission Guidelines to go with the Patch Submission Guidelines. Searching the site for 'bug reports' gives PEP 3 *Handling* (not submitting) Bug Reports as first hit. It seems to have last been revised 4-5 years ago. Is there anything more recent I should be aware of? PEP 3 references Appendix B. Reporting Bugs of the current docs. I believe this page could stand revision to be more list a checklist. The search engine does *not* return this page (current App. B) among the first 10 of 19,000 (really?) reported hits. I wish we could 'buy' words (for free) for searches on our own site or otherwise learn how to influence the search results. The top 10 do include the appendix for earlier versions. But this will won't help get people to the most recent version. The search engine also reports Known Bugs lists such as http://www.python.org/2.4/bugs.html. At the bottom is a very short blurb of how to report bugs, which does reference Appendix B (nor, of course, to your yet to be posted page). The same applies to http://www.python.org/dev/tools.html. I would really like to see one page, occasionally revised, that is referenced wherever the subject is discussed on the site. Some specifics based on my experience reviewing bugs, mostly as 'triage nurse'. I would like to see more emphasis that the Python SF bug list is for bugs in the PSF distribution, including documentation and std libs, which we can fix, and not for other stuff, including feature requests (see RFE tracker), non-bug change proposals (see PEPs), and bugs in 3rd party libraries and compilers (see their bug lists). I would like it stated that a bug is generally a discrepancy between promise -- the documentaion-- and performance -- the implementation. (Non-documentation is another area.) This means that 'reporting a bug' often means finding and reporting the section of the documentation -- the language or library reference -- that conflicts with the reported behavior. Many bugs reported today are not as obviously bugs as 2+2 5 I agree with Raymond that unittests are a nice optional extra but too much to expect. You could mention that providing good, simple code demonstrating the bug, perhaps with multiple data inputs, makes it easier for the bug fixer to write a test so that the bug will be caught if reintroduced. In summary, I think a good guideline page could improve reports and make first-reviews easier. Terry J. Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] checklist for filing a bug
In order to lower the barrier for reporting bugs, writing patches, and handling CVS commits, I am writing up checklists for each and I will put them up on python.org. The first checklist is for bug reports. All comments welcome. Keep in mind the list is supposed to be short and straight-forward; too wordy and people won't read it. Reporting a Bug +++ For technical question for any step listed, refer to the `dev FAQ`_. #. Make sure the bug is reproducible The bug cannot be a freak occurence and must be reproducible so developers can test against it. #. Isolate bug Come up with a code snippet that is as succinct as possible that triggers the bug consistently. Coding it as a unit test is the best. #. Gather important information Info such as Python version, operating system version, etc.; anything that might have influenced the code that lead to the bug. #. Report the bug on SourceForge_ Create a new tracker item, filling out the ``Category`` and ``Group`` fields. Do not set the ``Assigned To`` or ``Priority`` fields. Upload your code snippet as a file and make sure to click the ``Upload`` button! .. _dev FAQ: http://www.python.org/dev/devfaq.html .. _SourceForge: http://sourceforge.net/tracker/?group_id=5470atid=105470 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
