Mailman 3 April 2012 - Python-checkins

cpython (3.2): #14519: fix the regex used in the scanf example.
by ezio.melotti April 29, 2012

April 29, 2012

http://hg.python.org/cpython/rev/e317d651ccf8 changeset: 76625:e317d651ccf8 branch: 3.2 parent: 76621:2620641725bb user: Ezio Melotti <ezio.melotti(a)gmail.com> date: Sun Apr 29 11:47:28 2012 +0300 summary: #14519: fix the regex used in the scanf example. files: Doc/library/re.rst | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Doc/library/re.rst b/Doc/library/re.rst --- a/Doc/library/re.rst +++ b/Doc/library/re.rst @@ -1072,13 +1072,13 @@ +--------------------------------+---------------------------------------------+ | ``%i`` | ``[-+]?(0[xX][\dA-Fa-f]+|0[0-7]*|\d+)`` | +--------------------------------+---------------------------------------------+ -| ``%o`` | ``0[0-7]*`` | +| ``%o`` | ``[-+]?[0-7]+`` | +--------------------------------+---------------------------------------------+ | ``%s`` | ``\S+`` | +--------------------------------+---------------------------------------------+ | ``%u`` | ``\d+`` | +--------------------------------+---------------------------------------------+ -| ``%x``, ``%X`` | ``0[xX][\dA-Fa-f]+`` | +| ``%x``, ``%X`` | ``[-+]?(0[xX])?[\dA-Fa-f]+`` | +--------------------------------+---------------------------------------------+ To extract the filename and numbers from a string like :: -- Repository URL: http://hg.python.org/cpython

1 0

cpython (2.7): #14519: fix the regex used in the scanf example.
by ezio.melotti April 29, 2012

April 29, 2012

http://hg.python.org/cpython/rev/b26471a2a115 changeset: 76624:b26471a2a115 branch: 2.7 parent: 76620:de64931637cd user: Ezio Melotti <ezio.melotti(a)gmail.com> date: Sun Apr 29 11:47:28 2012 +0300 summary: #14519: fix the regex used in the scanf example. files: Doc/library/re.rst | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Doc/library/re.rst b/Doc/library/re.rst --- a/Doc/library/re.rst +++ b/Doc/library/re.rst @@ -1058,13 +1058,13 @@ +--------------------------------+---------------------------------------------+ | ``%i`` | ``[-+]?(0[xX][\dA-Fa-f]+|0[0-7]*|\d+)`` | +--------------------------------+---------------------------------------------+ -| ``%o`` | ``0[0-7]*`` | +| ``%o`` | ``[-+]?[0-7]+`` | +--------------------------------+---------------------------------------------+ | ``%s`` | ``\S+`` | +--------------------------------+---------------------------------------------+ | ``%u`` | ``\d+`` | +--------------------------------+---------------------------------------------+ -| ``%x``, ``%X`` | ``0[xX][\dA-Fa-f]+`` | +| ``%x``, ``%X`` | ``[-+]?(0[xX])?[\dA-Fa-f]+`` | +--------------------------------+---------------------------------------------+ To extract the filename and numbers from a string like :: -- Repository URL: http://hg.python.org/cpython

1 0

cpython: Better control when dumping import state
by nick.coghlan April 29, 2012

April 29, 2012

http://hg.python.org/cpython/rev/00221c8b7c86 changeset: 76623:00221c8b7c86 user: Nick Coghlan <ncoghlan(a)gmail.com> date: Sun Apr 29 17:58:24 2012 +1000 summary: Better control when dumping import state files: Tools/scripts/import_diagnostics.py | 22 +++++++--------- 1 files changed, 10 insertions(+), 12 deletions(-) diff --git a/Tools/scripts/import_diagnostics.py b/Tools/scripts/import_diagnostics.py --- a/Tools/scripts/import_diagnostics.py +++ b/Tools/scripts/import_diagnostics.py @@ -7,27 +7,25 @@ def _dump_state(args): print(sys.version) - print("sys.path:") - pprint(sys.path) - print("sys.meta_path") - pprint(sys.meta_path) - print("sys.path_hooks") - pprint(sys.path_hooks) - print("sys.path_importer_cache") - pprint(sys.path_importer_cache) - print("sys.modules:") - pprint(sys.modules) + for name in args.attributes: + print("sys.{}:".format(name)) + pprint(getattr(sys, name)) + +def _add_dump_args(cmd): + cmd.add_argument("attributes", metavar="ATTR", nargs="+", + help="sys module attribute to display") COMMANDS = ( - ("dump", "Dump import state", _dump_state), + ("dump", "Dump import state", _dump_state, _add_dump_args), ) def _make_parser(): parser = argparse.ArgumentParser() sub = parser.add_subparsers(title="Commands") - for name, description, implementation in COMMANDS: + for name, description, implementation, add_args in COMMANDS: cmd = sub.add_parser(name, help=description) cmd.set_defaults(command=implementation) + add_args(cmd) return parser def main(args): -- Repository URL: http://hg.python.org/cpython

1 0

cpython (3.2): Fix markup in unittest doc.
by ezio.melotti April 29, 2012

April 29, 2012

http://hg.python.org/cpython/rev/2620641725bb changeset: 76621:2620641725bb branch: 3.2 parent: 76618:6adad27fcc8c user: Ezio Melotti <ezio.melotti(a)gmail.com> date: Sun Apr 29 10:52:18 2012 +0300 summary: Fix markup in unittest doc. files: Doc/library/unittest.rst | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Doc/library/unittest.rst b/Doc/library/unittest.rst --- a/Doc/library/unittest.rst +++ b/Doc/library/unittest.rst @@ -1553,8 +1553,8 @@ The :class:`TestLoader` class is used to create test suites from classes and modules. Normally, there is no need to create an instance of this class; the :mod:`unittest` module provides an instance that can be shared as - ``unittest.defaultTestLoader``. Using a subclass or instance, however, allows - customization of some configurable properties. + :data:`unittest.defaultTestLoader`. Using a subclass or instance, however, + allows customization of some configurable properties. :class:`TestLoader` objects have the following methods: -- Repository URL: http://hg.python.org/cpython

1 0

cpython (merge 3.2 -> default): Merge markup fix in unittest doc from 3.2.
by ezio.melotti April 29, 2012

April 29, 2012

http://hg.python.org/cpython/rev/653f79e357f8 changeset: 76622:653f79e357f8 parent: 76619:f9f11998a20d parent: 76621:2620641725bb user: Ezio Melotti <ezio.melotti(a)gmail.com> date: Sun Apr 29 10:53:31 2012 +0300 summary: Merge markup fix in unittest doc from 3.2. files: Doc/library/unittest.rst | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Doc/library/unittest.rst b/Doc/library/unittest.rst --- a/Doc/library/unittest.rst +++ b/Doc/library/unittest.rst @@ -1547,8 +1547,8 @@ The :class:`TestLoader` class is used to create test suites from classes and modules. Normally, there is no need to create an instance of this class; the :mod:`unittest` module provides an instance that can be shared as - ``unittest.defaultTestLoader``. Using a subclass or instance, however, allows - customization of some configurable properties. + :data:`unittest.defaultTestLoader`. Using a subclass or instance, however, + allows customization of some configurable properties. :class:`TestLoader` objects have the following methods: -- Repository URL: http://hg.python.org/cpython

1 0

cpython (2.7): Fix markup in unittest doc.
by ezio.melotti April 29, 2012

April 29, 2012

http://hg.python.org/cpython/rev/de64931637cd changeset: 76620:de64931637cd branch: 2.7 parent: 76617:fb1e71c7619a user: Ezio Melotti <ezio.melotti(a)gmail.com> date: Sun Apr 29 10:52:18 2012 +0300 summary: Fix markup in unittest doc. files: Doc/library/unittest.rst | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Doc/library/unittest.rst b/Doc/library/unittest.rst --- a/Doc/library/unittest.rst +++ b/Doc/library/unittest.rst @@ -1426,8 +1426,8 @@ The :class:`TestLoader` class is used to create test suites from classes and modules. Normally, there is no need to create an instance of this class; the :mod:`unittest` module provides an instance that can be shared as - ``unittest.defaultTestLoader``. Using a subclass or instance, however, allows - customization of some configurable properties. + :data:`unittest.defaultTestLoader`. Using a subclass or instance, however, + allows customization of some configurable properties. :class:`TestLoader` objects have the following methods: -- Repository URL: http://hg.python.org/cpython

1 0

cpython (merge 3.2 -> default): issue6085 - update docs in default branch
by senthil.kumaran April 29, 2012

April 29, 2012

http://hg.python.org/cpython/rev/f9f11998a20d changeset: 76619:f9f11998a20d parent: 76616:db39b9513e71 parent: 76618:6adad27fcc8c user: Senthil Kumaran <senthil(a)uthcode.com> date: Sun Apr 29 13:44:14 2012 +0800 summary: issue6085 - update docs in default branch files: Doc/library/http.server.rst | 2 +- Lib/http/server.py | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Doc/library/http.server.rst b/Doc/library/http.server.rst --- a/Doc/library/http.server.rst +++ b/Doc/library/http.server.rst @@ -248,7 +248,7 @@ to create custom error logging mechanisms. The *format* argument is a standard printf-style format string, where the additional arguments to :meth:`log_message` are applied as inputs to the formatting. The client - address and current date and time are prefixed to every message logged. + ip address and current date and time are prefixed to every message logged. .. method:: version_string() diff --git a/Lib/http/server.py b/Lib/http/server.py --- a/Lib/http/server.py +++ b/Lib/http/server.py @@ -518,7 +518,7 @@ specified as subsequent arguments (it's just like printf!). - The client host and current date/time are prefixed to + The client ip and current date/time are prefixed to every message. """ -- Repository URL: http://hg.python.org/cpython

1 0

cpython (3.2): Fix issue6085 - Remove the delay caused by fqdn lookup while logging in
by senthil.kumaran April 29, 2012

April 29, 2012

http://hg.python.org/cpython/rev/6adad27fcc8c changeset: 76618:6adad27fcc8c branch: 3.2 parent: 76615:da9179248118 user: Senthil Kumaran <senthil(a)uthcode.com> date: Sun Apr 29 13:41:03 2012 +0800 summary: Fix issue6085 - Remove the delay caused by fqdn lookup while logging in BaseHTTPRequestHandler files: Doc/library/http.server.rst | 2 +- Lib/http/server.py | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Doc/library/http.server.rst b/Doc/library/http.server.rst --- a/Doc/library/http.server.rst +++ b/Doc/library/http.server.rst @@ -229,7 +229,7 @@ to create custom error logging mechanisms. The *format* argument is a standard printf-style format string, where the additional arguments to :meth:`log_message` are applied as inputs to the formatting. The client - address and current date and time are prefixed to every message logged. + ip address and current date and time are prefixed to every message logged. .. method:: version_string() diff --git a/Lib/http/server.py b/Lib/http/server.py --- a/Lib/http/server.py +++ b/Lib/http/server.py @@ -508,13 +508,13 @@ specified as subsequent arguments (it's just like printf!). - The client host and current date/time are prefixed to + The client ip and current date/time are prefixed to every message. """ sys.stderr.write("%s - - [%s] %s\n" % - (self.address_string(), + (self.client_address[0], self.log_date_time_string(), format%args)) -- Repository URL: http://hg.python.org/cpython

1 0

cpython (2.7): Fix issue6085 - Remove the delay caused by fqdn lookup while logging in
by senthil.kumaran April 29, 2012

April 29, 2012

http://hg.python.org/cpython/rev/fb1e71c7619a changeset: 76617:fb1e71c7619a branch: 2.7 parent: 76611:7c262962b681 user: Senthil Kumaran <senthil(a)uthcode.com> date: Sun Apr 29 13:39:16 2012 +0800 summary: Fix issue6085 - Remove the delay caused by fqdn lookup while logging in BaseHTTPRequestHandler files: Doc/library/basehttpserver.rst | 2 +- Lib/BaseHTTPServer.py | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/Doc/library/basehttpserver.rst b/Doc/library/basehttpserver.rst --- a/Doc/library/basehttpserver.rst +++ b/Doc/library/basehttpserver.rst @@ -240,7 +240,7 @@ to create custom error logging mechanisms. The *format* argument is a standard printf-style format string, where the additional arguments to :meth:`log_message` are applied as inputs to the formatting. The client - address and current date and time are prefixed to every message logged. + ip address and current date and time are prefixed to every message logged. .. method:: version_string() diff --git a/Lib/BaseHTTPServer.py b/Lib/BaseHTTPServer.py --- a/Lib/BaseHTTPServer.py +++ b/Lib/BaseHTTPServer.py @@ -447,13 +447,13 @@ specified as subsequent arguments (it's just like printf!). - The client host and current date/time are prefixed to - every message. + The client ip address and current date/time are prefixed to every + message. """ sys.stderr.write("%s - - [%s] %s\n" % - (self.address_string(), + (self.client_address[0], self.log_date_time_string(), format%args)) -- Repository URL: http://hg.python.org/cpython

1 0

devguide: #119: reorganize the tracker documentation in the devguide.
by ezio.melotti April 29, 2012

April 29, 2012

http://hg.python.org/devguide/rev/252e2aabc87a changeset: 503:252e2aabc87a user: Ezio Melotti <ezio.melotti(a)gmail.com> date: Sun Apr 29 08:37:40 2012 +0300 summary: #119: reorganize the tracker documentation in the devguide. files: devrole.rst | 24 ---- helptriage.rst | 63 ----------- index.rst | 8 +- languishing.rst | 26 ---- tracker.rst | 197 ++++++++++++++++++++++++++++++++++++ triaging.rst | 7 - 6 files changed, 199 insertions(+), 126 deletions(-) diff --git a/devrole.rst b/devrole.rst deleted file mode 100644 --- a/devrole.rst +++ /dev/null @@ -1,24 +0,0 @@ -.. _devrole: - -Gaining the "Developer" Role on the Issue Tracker -================================================= - -When you have consistently shown the ability to properly -:ref:`help triage issues <helptriage>` without guidance, you may request that you -be given the "Developer" role on the `issue tracker`_. You can make the request -of any person who already has the Developer role. If they decide you are ready -to gain the extra privileges on the tracker they will then act as a mentor to -you until you are ready to do things entirely on your own. There is no set rule -as to how many issues you need to have helped with before or how long you have -been participating. The key requirements are that you show the desire to -help, you are able to work well with others (especially those already with the -Developer role), and that have a firm grasp of how to do things on the issue -tracker properly on your own. - -Gaining the Developer role will allow you to set any value on any issue in the -tracker, releasing you from the burden of having to ask others to set values on -an issue for you in order to properly triage something. This will not only help -speed up and simplify your work in helping out, but also help lessen the -workload for everyone by gaining your help. - -.. _issue tracker: http://bugs.python.org diff --git a/helptriage.rst b/helptriage.rst deleted file mode 100644 --- a/helptriage.rst +++ /dev/null @@ -1,65 +0,0 @@ -.. _helptriage: - -Helping Triage Issues -===================== - -Once you know your way around how Python's source files are -structured and you are comfortable working with patches, a great way to -participate is to help triage issues. Do realize, though, that experience -working on Python is needed in order to effectively help triage. - -Around the clock, new issues are being opened on the `issue tracker`_ and -existing issues are being updated. Every -issue needs to be triaged to make sure various things are in proper order. Even -without special privileges you can help with this process. - - -Bugs ----- - -For bugs, an issue needs to: - -* clearly explain the bug so it can be reproduced -* include all relevant platform details -* state what version(s) of Python are affected by the bug. - -These are things you can help with once you have experience developing for -Python. For instance, if a bug is not clearly explained enough for you to -reproduce it then there is a good chance a core developer won't be able to -either. And it is always helpful to know if a bug not only affects the -in-development version of Python, but whether it also affects other versions in -maintenance mode. And if the bug lacks a unit test that should end up in -Python's test suite, having that written can be very helpful. - -This is all helpful as it allows triagers (i.e., -:ref:`people with the Developer role on the issue tracker <devrole>`) to -properly classify an issue so it can be handled by the right core developers in -a timely fashion. - - -Patches -------- - -If an issue has a patch attached that has not been reviewed, you can help by -making sure the patch: - -* follows the style guides -* applies cleanly to an up-to-date checkout -* is a good solution to the problem it is trying to solve -* includes proper tests -* includes proper documentation changes -* submitter is listed in ``Misc/ACKS``, either already or the patch adds them - -Doing all of this allows core developers and :ref:`triagers <devrole>` to more -quickly look for subtle issues that only people with extensive experience -working on Python's code base will notice. - -There is a complete list of `open issues with patches`_ as well as a list of -`issues needing a review`_, although make sure -that someone has not already done the checklist above as it is possible the -issue is still open for reasons other than needing help being triaged. - - -.. _issue tracker: http://bugs.python.org -.. _issues needing a review: http://bugs.python.org/issue?status=1&@sort=-activity&@columns=id,activity,… -.. _open issues with patches: http://bugs.python.org/issue?status=1&@sort=-activity&@columns=id,activity,… diff --git a/index.rst b/index.rst --- a/index.rst +++ b/index.rst @@ -13,10 +13,8 @@ documenting silencewarnings fixingissues - helptriage - devrole + tracker triaging - languishing communication coredev developers @@ -89,10 +87,8 @@ * :doc:`silencewarnings` * Fixing issues found by the :doc:`buildbots <buildbots>` * :doc:`fixingissues` - * :doc:`helptriage` -* :doc:`devrole` +* :ref:`tracker` and :ref:`helptriage` * :doc:`triaging` - * :doc:`languishing` * :doc:`communication` * :doc:`coredev` * :doc:`committing` diff --git a/languishing.rst b/languishing.rst deleted file mode 100644 --- a/languishing.rst +++ /dev/null @@ -1,26 +0,0 @@ -.. _languishing: - -Marking Issues as "Languishing" -=============================== - -Sometimes an issue has no clear answer. It can be because core developers -cannot agree on the proper solution (or if a problem even exists). Other -times a solution is agreed upon but writing the code for the solution would -take too much effort for little gain, and so no one wants to do the work (or -would simply break too much pre-existing code without a different solution). - -In these cases an issue will languish_ in the `issue tracker`_, and its -status should be set as such. This -serves the purpose of preventing people who are trying to :ref:`fix issues -<fixingissues>` from wasting time on issues that even core developers cannot -come up with an agreed-upon solution for. - -A good way to tell if an issue is languishing is based on whether it had -an in-depth discussion that stalled several months ago. In that instance it is -typically safe to set the status of the issue to "languishing". If you are -unsure you can always leave a comment on the issue asking if others agree that -it is languishing. - - -.. _issue tracker: http://bugs.python.org -.. _languish: http://bugs.python.org/issue?@columns=title,id,activity,status&@sort=activi… diff --git a/tracker.rst b/tracker.rst new file mode 100644 --- /dev/null +++ b/tracker.rst @@ -0,0 +1,197 @@ +.. _tracker: + +Using the Issue Tracker +======================= + +If you think you found a bug in Python, you can report it to the +`issue tracker`_. Documentation bugs can also be reported there. +Issues about the tracker should be reported to the `meta tracker`_. + + +Checking if a bug already exists +-------------------------------- + +The first step in filing a report is to determine whether the problem has +already been reported. The advantage in doing so, aside from saving the +developers time, is that you learn what has been done to fix it; it may be that +the problem has already been fixed for the next release, or additional +information is needed (in which case you are welcome to provide it if you can!). + +To do this, search the bug database using the search box on the top of the page. +An `advanced search`_ is also available by clicking on "Search" in +the sidebar. + + +Reporting an issue +------------------ + +If the problem you're reporting is not already in the `issue tracker`_, you +need to log in by entering your user and password in the form on the left. +If you don't already have a tracker account, select the "Register" link or, +if you use OpenID, one of the OpenID provider logos in the sidebar. + +It is not possible to submit a bug report anonymously. + +Being now logged in, you can submit a bug by clicking on the "Create New" link +in the sidebar. + +The submission form has a number of fields, and they are described in detail +in the :ref:`triaging` page. This is a short summary: + +* in the **Title** field, enter a *very* short description of the problem; + less than ten words is good; +* in the **Type** field, select the type of your problem (usually behavior); +* if you know which **Components** and **Versions** are affected by the issue, + you can select these too; +* if you have JavaScript enabled, you can use the **Nosy List** field to search + developers that can help with the issue by entering the name of the affected + module, operating system, or interest area. +* least but not last, you have to describe the problem in detail, including + what you expected to happen and what did happen, in the **Comment** field. + Be sure to include whether any extension modules were involved, and what + hardware and software platform you were using (including version information + as appropriate). + +The triaging team will take care of setting other fields, and possibly assign +the issue to a specific developer. You will automatically receive an update +each time an action is taken on the bug. + + +.. _helptriage: + +Helping Triage Issues +===================== + +Once you know your way around how Python's source files are +structured and you are comfortable working with patches, a great way to +participate is to help triage issues. Do realize, though, that experience +working on Python is needed in order to effectively help triage. + +Around the clock, new issues are being opened on the `issue tracker`_ and +existing issues are being updated. Every +issue needs to be triaged to make sure various things are in proper order. Even +without special privileges you can help with this process. + + +Classifying Reports +------------------- + +For bugs, an issue needs to: + +* clearly explain the bug so it can be reproduced +* include all relevant platform details +* state what version(s) of Python are affected by the bug. + +These are things you can help with once you have experience developing for +Python. For instance, if a bug is not clearly explained enough for you to +reproduce it then there is a good chance a core developer won't be able to +either. And it is always helpful to know if a bug not only affects the +in-development version of Python, but whether it also affects other versions in +maintenance mode. And if the bug lacks a unit test that should end up in +Python's test suite, having that written can be very helpful. + +This is all helpful as it allows triagers (i.e., +:ref:`people with the Developer role on the issue tracker <devrole>`) to +properly classify an issue so it can be handled by the right core developers in +a timely fashion. + + +Reviewing Patches +----------------- + +If an issue has a patch attached that has not been reviewed, you can help by +making sure the patch: + +* follows the style guides +* applies cleanly to an up-to-date clone +* is a good solution to the problem it is trying to solve +* includes proper tests +* includes proper documentation changes +* submitter is listed in ``Misc/ACKS``, either already or the patch adds them + +Doing all of this allows core developers and :ref:`triagers <devrole>` to more +quickly look for subtle issues that only people with extensive experience +working on Python's code base will notice. + + +Finding an Issue You Can Help With +---------------------------------- + +If you want to help triaging issues, you might also want to search for issues +that you are knowledgeable about. An easy way to do it, is to search for +the name of a module you are familiar with. You can also use the +`advanced search`_ and search for specific components (e.g. "Windows" if you +are a Windows developer, "Extension Modules" if you are familiar with C, etc.). +Finally you can use the "Random issue" link in the sidebar to pick random +issues until you find an issue that you like. Is not so uncommon to find old +issues that can be closed, either because they are no longer valid, or +because they have a patch that is ready to be committed, but no one had +time to do it yet. + +In the sidebar you can also find links to summaries for easy issues and +issues with a patch. + + +.. _devrole: + +Gaining the "Developer" Role on the Issue Tracker +------------------------------------------------- + +When you have consistently shown the ability to properly +help triage issues without guidance, you may request that you +be given the "Developer" role on the `issue tracker`_. You can make the request +of any person who already has the Developer role. If they decide you are ready +to gain the extra privileges on the tracker they will then act as a mentor to +you until you are ready to do things entirely on your own. There is no set rule +as to how many issues you need to have helped with before or how long you have +been participating. The key requirements are that you show the desire to +help, you are able to work well with others (especially those already with the +Developer role), and that have a firm grasp of how to do things on the issue +tracker properly on your own. + +Gaining the Developer role will allow you to set any value on any issue in the +tracker, releasing you from the burden of having to ask others to set values on +an issue for you in order to properly triage something. This will not only help +speed up and simplify your work in helping out, but also help lessen the +workload for everyone by gaining your help. + + +The Meta Tracker +================ + +If you find an issue with the `issue tracker`_, you can report it to the +`meta tracker`_. The meta tracker is where you file issues against anything +you come across when working with the issue tracker itself (e.g you can't +attach a file, the layout is broken on your browser, Rietveld gave you an +error, etc.). + +If you want to contribute to the tracker you can get a checkout of the source +and install a local instance where to experiment. You can find detailed +instructions on the `Tracker Development`_ page. + + +.. seealso:: + + `The Python issue tracker <http://bugs.python.org/>`_ + Where to report issues about Python. + + `The New-bugs-announce mailing list <http://mail.python.org/mailman/listinfo/new-bugs-announce>`_ + Where all the new issues created on the tracker are reported. + + `The Python-bugs-list mailing list <http://mail.python.org/mailman/listinfo/python-bugs-list>`_ + Where all the changes to issues are reported. + + `The meta tracker <http://psf.upfronthosting.co.za/roundup/meta/>`_ + Where to report issues about the tracker itself. + + `The Tracker development wiki page <http://wiki.python.org/moin/TrackerDevelopment>`_ + Instructions about setting up a local instance of the bug tracker. + + `The Tracker-discuss mailing list <http://mail.python.org/mailman/listinfo/tracker-discuss>`_ + Discussions about the bug tracker. + + +.. _issue tracker: http://bugs.python.org/ +.. _meta tracker: http://psf.upfronthosting.co.za/roundup/meta/ +.. _advanced search: http://bugs.python.org/issue?@template=search +.. _Tracker Development: http://wiki.python.org/moin/TrackerDevelopment diff --git a/triaging.rst b/triaging.rst --- a/triaging.rst +++ b/triaging.rst @@ -289,13 +289,6 @@ the Devguide, this page, and this section respectively. -Reporting Issues About the Tracker ----------------------------------- -The `meta tracker`_ is the tracker about the issue tracker. It is where you -file issues against anything you come across when working with the issue -tracker itself. - - .. _Doc: http://hg.python.org/cpython/file/default/Doc/ .. _Grammar: http://hg.python.org/cpython/file/default/Grammar/ .. _Lib: http://hg.python.org/cpython/file/default/Lib/ @@ -326,4 +319,3 @@ .. _Developer's guide: http://hg.python.org/devguide/ .. _GSoC: http://code.google.com/soc/ .. _issue tracker: http://bugs.python.org -.. _meta tracker: http://psf.upfronthosting.co.za/roundup/meta/ -- Repository URL: http://hg.python.org/devguide

1 0