PEP 3: バグ報告の取扱いに関するガイドライン(廃止) ==================================================== 原文: http://www.python.org/dev/peps/pep-0003/ +---------------+-------------------------------------+ | PEP | 3 | +---------------+-------------------------------------+ | Title | Guidelines for Handling Bug Reports | +---------------+-------------------------------------+ | Version | $Revision$ | +---------------+-------------------------------------+ | Last-Modified | $Date$ | +---------------+-------------------------------------+ | Author | jeremy@alum.mit.edu (Jeremy Hylton) | +---------------+-------------------------------------+ | Status | Withdrawn | +---------------+-------------------------------------+ | Type | Process | +---------------+-------------------------------------+ | Created | 25-Sep-2000 | +---------------+-------------------------------------+ | Post-History | | +---------------+-------------------------------------+ .. Introduction ---------------- イントロダクション -------------------------------- .. This PEP contained guidelines for handling bug reports in the Python bug tracker. It has been replaced by the Issue Workflow described at このPEPはPythonバグトラッカー内でバグ報告を扱うためのガイドラインが記述さ れています。これは以下のURLに記されている問題解決ワークフロー(Issue Workflow)で置き換えられました。 http://www.python.org/dev/workflow/ .. Guidelines for people submitting Python bugs are at Pythonのバグを報告する人々のためのガイドラインはこちらです。 http://docs.python.org/bugs.html .. Original Guidelines ----------------------- 元々のガイドライン ----------------------- .. 1. Make sure the bug category and bug group are correct. If they are correct, it is easier for someone interested in helping to find out, say, what all the open Tkinter bugs are. 1. バグのカテゴリとグループが正しいかどうか確認してください。もし正しいの であれば、未解決のバグリストから、興味がある誰かが助けるときに見つけやす くなります。 .. 2. If it's a minor feature request that you don't plan to address right away, add it to PEP 42 or ask the owner to add it for you. If you add the bug to PEP 42, mark the bug as "feature request", "later", and "closed"; and add a comment to the bug saying that this is the case (mentioning the PEP explicitly). XXX do we prefer the tracker or PEP 42? 2. もし、それがあなたが思っていないような瑣末な機能の要求であるばあい、 そのバグをPEP 42に加え、"feature request(機能要求)", "later(後で)", "closed(解決済み)"としてください。また、PEPで明白に述べられている状況 であると、そのバグに関するコメントに書いてください。 XXX PEP 42にいれるより、trackerにいれたほうがいい？ .. 3. Assign the bug a reasonable priority. We don't yet have a clear sense of what each priority should mean. One rule, however, is that bugs with priority "urgent" or higher must be fixed before the next release. 3. 適切な優先度を割り振ってください。ただ、まだ我々は優先度がなにを意味す るかに関して明確な基準を持っていません。ただし、一つだけあるルールは、 そのバグが"urgent(緊急)"かそれ以上の優先度の場合、次のリリースまでの 間に直さなければならない、ということです。 .. 4. If a bug report doesn't have enough information to allow you to reproduce or diagnose it, ask the original submitter for more information. If the original report is really thin and your email doesn't get a response after a reasonable waiting period, you can close the bug. 4. もしバグレポートが再現や診断するのに必要な情報を持っていない場合、元々 の投稿者にもっと情報を欲しいとお願いしてください。もし、元々のレポー トが本当に情報量が少なく、メールを送っても適切な期間返事がない場合、 そのバグを閉じても構いません。 .. 5. If you fix a bug, mark the status as "Fixed" and close it. In the comments, include the SVN revision numbers of the commit(s). In the SVN checkin message, include the issue number *and* a normal description of the change, mentioning the contributor if a patch was applied. 5. もしバグを解決したら、ステータスを"Fixed(解決済み)"とし、閉じてくださ い。コメントには、コミットのSVNのリビジョン番号を含めてください。SVN のチェックインメッセージには、問題番号 **に加えて** 通常と同じ変更の説 明と、パッチが受け入れられた場合の貢献者の記述を含めてください。 .. 6. If you are assigned a bug that you are unable to deal with, assign it to someone else if you think they will be able to deal with it, otherwise it's probably best to unassign it. 6. もしあなたが解決できないバグを割り当てられた場合、解決出きると思われる 人に割り当ててください。あるいは、誰も割り当てないのが一番かもしれませ ん。 .. References ------------- 参考文献 ------------- [1] http://bugs.python.org/ Local Variables: coding: utf-8 End: