This page outlines a plan to improve the Bug Tracker at http://bugs.python.org.
While migrating to Git/GitHub, the following things need to be done:
A new detector that converts patches to pull requests should be written. The tracker will probably require:
- a local git clone of cpython where to commit patches;
- a github account used to post pull requests;
- a github clone of cpython;
This is an outline of its possible functioning:
- a new patch is submitted and triggers the detector;
- the detector commits the patch on its local clone;
- the detector pushes the patch on its github clone;
- the detector sends a pull request to the official CPython clone;
- the detector adds a link to the newly created PR on the issue page;
- should the detector create a separate branch for every issue/patch?
- is it possible to use the correct author/committer on step 2?
- is it possible to skip step 3 and send the PR from the local clone?
- are there better approaches?
A new list for PRs should be added after the attachments list:
|PR 123||ezio.melotti||Merged||Fix issue #12345|||
|PR 125||ezio.melotti||Open||Improve docs|||
|PR [___] [Add New Pull Request]|
The list is updated when:
- a patch is uploaded and a PR is automatically created;
- the user enters a PR number in the specific field at the bottom;
The list might also be updated when:
- through an API call (if/when the REST API is added to Roundup it should work out of the box);
- a PR number is mentioned in a message
- pro: mentioning the PR num in the message is enough -- no need to write it in the field;
- pro: useful for bots that can't edit fields and only send messages via email;
- cons: if the PR of a related issue is mentioned it will be included too;
- a "GitHub account name" field for users;
- auto-nosy to the issue for users that submit a PR;
- conditional auto-closing of issues when PR is merged;
- an API to check the CLA from GitHub;
Certain things in the UI may trigger depending on how the user is classified. The current roundup 'Developer' role is modified into the following sub-roles:
- Release Manager
Change possible 'resolved' states to the following:
- won't fix
- not a bug
- third party
These 6 states are already present, but there are 5 additional ones that should be removed: later, out of date, rejected, remind, works for me.
Replace both 'components' and 'keywords' by a more comprehensive tagging system. Initially at least these will all be 'official' tags, listed in the developer's guide and settable via autocomplete in a text field. The list of values should be every category currently in the experts list, plus:
- resource usage
- security issue
- bite sized
- release blocker (for each active release)
- deferred blocker (for each active release)
Change Types to:
Change 'assigned to' so that it can be any valid user, and it is automatically reset to 'no one' after N days or an issue state change.
New 'state' field will eventually replace both 'stage' and 'status' (see http://imgur.com/a/UgJBJ for a diagram).
- information needed
- decision needed
- patch needed
- review needed
- patch update needed
- commit review needed
- resolved (with one of the resolved states)
- Have only title/message/state in the default user view, with a sticky (either per-user or per-browser (via cookies)) setting to also show the other fields. (No 'state' in the 'new issue' view).
- Show the role of users (normal user, developer/triager, committer) with an icon or tooltip
- DONE Show a "clip" icon in the issue list page for issues with a patch (see http://psf.upfronthosting.co.za/roundup/meta/issue550)
Add a dashboard page similar to https://dashboard.djangoproject.com/ (global + per user?).
Experiment with a dashboard that actually lists the top messages in each state, arranged in the order of interest to the user based on their role (user, triager, committer).
'stuck' issues are sorted to bottom of queue.
'information needed' queue should list only issues that have been in that state for longer than N days.