Patch and Test Tracking

Instead of the 'needs test' and 'needs patch' stages, it would be better to have a checkbox grid something like this:

            NA      needs patch     has patch
docs       ( )          ( )           ( )
tests      ( )          ( )           ( )
code       ( )          ( )           ( )

We could then have a 'patch incomplete' stage instead of the 'needs' stages, where the checkboxes would make clear what things were missing.

Python Version Tracking

Instead of a multi-selection list for python versions, perhaps we could have a list of versions like this:

        confirmed   will apply  committed
3.3        ( )         ( )      [      ]
3.2        ( )         ( )      [      ]
3.1        ( )         ( )      [      ]
3.0        ( )         ( )      [      ]
2.7        ( )         ( )      [      ]
     ...

This would allow the tracker to record which versions a bug is present in, even if it doesn't get fixed in that version, and also allow us to track the progress when more than one version needs to be patched. We might perhaps want to add a stage 'committing' when a patch has been committed to one branch but not all. (Note: for feature requests 'confirmed' would be left blank). 'will apply' would be checked when someone determines that the patch, whether it exists or not, should be applied to the given branch. 'committed' would be the revision in which the patch was committed. Ideally this would be auto-filled by the change management system based on tags in the commit message.

If the above is deemed too complex, then we should at least have a way to mark issues as accepted regardless of whether or not they have a complete patch. This is to differentiate between issues that just need work, and issues where we haven't even decided that we are going to accept it.

• Waiting for the switch to Mercurial before writing code for auto-linking between bugs and changesets and such things may be smart. —merwok

This doesn't need a patch, but is noted here so the idea doesn't get lost: it has been suggested that an additional type of 'refactoring' be added.

New Field for Module/Package

When I want to find all bugs related to one module or package, I have to use the plain text search, which could give false positives and leave out valid results. For some packages I can use a component, e.g. Distutils, but not for all. I suggest a new field that would allow selecting what module(s)/package(s) a bug apply to. This would provide reliable and discoverable URIs for people who want to monitor particular modules or packages.

This has been suggested and rejected a number of times on python-dev. --RDM

This information is not useful. Can you list the arguments? -- [[techtonik]] <<DateTime(2010-04-30T09:06:27Z)>>

Open issues: Providing Atom feeds; using OpenSearch; HTML widget to use; renamed modules in 3.x; autonosy and auto-assignee. I can expand if someone asks. —merwok

Roundup has the capability to do auto-nosy and auto-assign, so you'll definitely need to expand on that one. --RDM

Misc

When an issue is closed stage should be automatically set to 'committed/rejected'.

• confusing, 'fixed' issue is neither 'committed' nor 'rejected' at all times -- anatoly techtonik

There should be a field in which you can enter an issue number of an issue of which this issue is a duplicate, and submitting it should

1. merge the nosy list from this issue into the specified issue
2. set the resolution to duplicate

3. close the issue (setting stage to committed/rejected per above)

   • duplicate would be better -- anatoly techtonik

There should be an anchor at the top of the page linked to the last message and other links to go back to the top of the page. This is especially useful when there are lot of messages.

It would probably be better if the default search returned results from closed bugs; this should cut down on the number of bug reports for things that have already been fixed but not released. See #311.

When a user adds a file there should be a note among the messages (or even inside the message) with a link to the added file. This would avoid confusion if the user says "This patch ..." and there are several files attached.

The tracker should be in some way integrated with maintainers.rst. It should be possible to map at least some of the "Components" in the tracker with the "Interest areas" (e.g. "Unicode", "Windows") in maintainers.rst and/or provide a way to consult the file while adding/editing an issue. Another option is to add fields like "maintainer of" or "interest areas" to the users, but it will probably be hard to keep it in sync with maintainers.rst.

CategoryTracker