|
Size: 329
Comment:
|
← Revision 13 as of 2016-01-05 05:47:11 ⇥
Size: 6713
Comment: Add a few more items about the Roundup/GitHub integration.
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| Hello from Italy. I'm glad to be here. My first name is Roosevelt. <<BR>> I live in a small city called San Martino Di Durasca in nothern Italy.<<BR>> I was also born in San Martino Di Durasca 28 years ago. Married in October year 1999. I'm working at the university.<<BR>> <<BR>> Also visit my web site frank kern tripwire |
#FORMAT rst This page outlines a plan to improve the Bug Tracker at http://bugs.python.org. See also the TrackerDevelopment_ page and the DesiredTrackerFeatures_ pages. .. contents:: :class: table-of-contents Git/GitHub integration ====================== While migrating to Git/GitHub, the following things need to be done: Converting patches to Pull Requests ----------------------------------- 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: 1. a new patch is submitted and triggers the detector; 2. the detector commits the patch on its local clone; 3. the detector pushes the patch on its github clone; 4. the detector sends a pull request to the official CPython clone; 5. the detector adds a link to the newly created PR on the issue page; Issues: * 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? Pull Request List ----------------- A new list for PRs should be added after the attachments list: +----------+--------------+--------+------------------+--------+ | PR | Author | Status | Comment | Edit | +==========+==============+========+==================+========+ | PR 123 | ezio.melotti | Merged | Fix issue #12345 | [edit] | +----------+--------------+--------+------------------+--------+ | PR 125 | ezio.melotti | Open | Improve docs | [edit] | +----------+--------------+--------+------------------+--------+ | 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; Other Roundup/GitHub integrations --------------------------------- * 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; Auto-generated Links -------------------- The `extension that generates links <https://hg.python.org/tracker/python-dev/file/tip/extensions/local_replace.py>`_, also needs to be updated: * update cs ids links to point to https://hg.python.org/lookup/ (see `this message <https://mail.python.org/pipermail/python-committers/2016-January/003691.html>`_). * update path links to point to GitHub; * add links to pull requests on GitHub when "PR num" or "pull request num" are used in messages; Workflow ======== 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: * Triage * Committer * Release Manager Change possible 'resolved' states to the following: * fixed * won't fix * duplicate * postponed * 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 * performance * security issue * segfault/abort * stuck * buildbot * bite sized * release blocker (for each active release) * deferred blocker (for each active release) Change Types to: * documentation * bug * enhancement 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). * new * information needed * decision needed * patch needed * review needed * patch update needed * commit review needed * resolved (with one of the resolved states) Priority: * high * normal * low Other features ============== Patch-related improvements -------------------------- When a file is submitted the tracker should be able to: * Determine if the file is a patch or not * Determine what files are affected by the patch (and possibly add the module/package names as tags) * Determine if the patch contains tests, docs, Misc/NEWS entry, Misc/ACKS, What's New (etc?) * Determine if the patch contains trailing whitespace or PEP 8 violations * Determine on which branches the patches apply on without conflicts (with a way to re-check it on demand or periodically) Somewhat controversial: a set of checkboxes for the items from the above that are required for this particular issue's patch. User Interface ============== * 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) Dashboard(s) ------------ 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. ---- CategoryTracker_ |
This page outlines a plan to improve the Bug Tracker at http://bugs.python.org.
See also the TrackerDevelopment page and the DesiredTrackerFeatures pages.
Contents
Git/GitHub integration
While migrating to Git/GitHub, the following things need to be done:
Converting patches to Pull Requests
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;
Issues:
- 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?
Pull Request List
A new list for PRs should be added after the attachments list:
| PR | Author | Status | Comment | Edit |
|---|---|---|---|---|
| PR 123 | ezio.melotti | Merged | Fix issue #12345 | [edit] |
| PR 125 | ezio.melotti | Open | Improve docs | [edit] |
| 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;
Other Roundup/GitHub integrations
- 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;
Auto-generated Links
The extension that generates links, also needs to be updated:
- update cs ids links to point to https://hg.python.org/lookup/ (see this message).
- update path links to point to GitHub;
- add links to pull requests on GitHub when "PR num" or "pull request num" are used in messages;
Workflow
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:
- Triage
- Committer
- Release Manager
Change possible 'resolved' states to the following:
- fixed
- won't fix
- duplicate
- postponed
- 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
- performance
- security issue
- segfault/abort
- stuck
- buildbot
- bite sized
- release blocker (for each active release)
- deferred blocker (for each active release)
Change Types to:
- documentation
- bug
- enhancement
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).
- new
- information needed
- decision needed
- patch needed
- review needed
- patch update needed
- commit review needed
- resolved (with one of the resolved states)
Priority:
- high
- normal
- low
User Interface
- 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)
Dashboard(s)
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.