Another summit, another potential time to see if people want to change anything about the issue tracker. I would bring up:
- Dropping Stage in favor of some keywords (e.g. 'needs unit test', 'needs docs') - Adding a freestyle text box to delineate which, if any, stdlib module is the cause of a bug and tie that into Misc/maintainers.rst; would potentially scale back the Component box
-Brett
Brett Cannon brett@python.org writes:
Another summit, another potential time to see if people want to change anything about the issue tracker.
It requires some coding, but I see OpenID authentication support URL:http://issues.roundup-tracker.org/issue2550523 to be important for lowering the barrier to getting bug reports.
Brett Cannon wrote:
Another summit, another potential time to see if people want to change anything about the issue tracker. I would bring up:
- Dropping Stage in favor of some keywords (e.g. 'needs unit test',
'needs docs')
- Adding a freestyle text box to delineate which, if any, stdlib module
is the cause of a bug and tie that into Misc/maintainers.rst; would potentially scale back the Component box
+lots on adding a module field (independent of automatically adding maintainers to the nosy list, it would assist in "I just did a major cleanup of module X, are there any old bugs I can kill off").
Of course, it will take a while for the field to be filled in on existing issues, but even having it be possible would be very nice.
Cheers, Nick.
+lots on adding a module field (independent of automatically adding maintainers to the nosy list, it would assist in "I just did a major cleanup of module X, are there any old bugs I can kill off").
Link (1:1) or Multilink (1:n)? What is the impact on the Component field?
Would you be willing to manage the field (in the sense of managing the set of values)? If so, please send me a list of values.
Regards, Martin
Martin v. Löwis wrote:
+lots on adding a module field (independent of automatically adding maintainers to the nosy list, it would assist in "I just did a major cleanup of module X, are there any old bugs I can kill off").
Link (1:1) or Multilink (1:n)? What is the impact on the Component field?
I was thinking multilink, and leaving component alone - the module field would largely come into play when the component was just the "Lib" catch-all.
Would you be willing to manage the field (in the sense of managing the set of values)? If so, please send me a list of values.
I would suggest just using the module index from the documentation to seed any such list of modules in the tracker: http://docs.python.org/modindex.html
Packages could generally be left as a single entry in the list. The only exception I think is that there should be an "xml.etree" entry separate from the main "xml" entry, and perhaps a separate entry for "os.path".
Deprecated modules could either be left out of the list, or else moved to appear at the end.
Regards, Nick.
On Fri, Oct 23, 2009 at 1:49 AM, Nick Coghlan ncoghlan@gmail.com wrote:
Brett Cannon wrote:
Another summit, another potential time to see if people want to change anything about the issue tracker. I would bring up:
- Dropping Stage in favor of some keywords (e.g. 'needs unit test',
'needs docs')
- Adding a freestyle text box to delineate which, if any, stdlib module
is the cause of a bug and tie that into Misc/maintainers.rst; would potentially scale back the Component box
+lots on adding a module field (independent of automatically adding maintainers to the nosy list, it would assist in "I just did a major cleanup of module X, are there any old bugs I can kill off").
yet another feature request or two to be lost to a mailing list thread along those lines:
Maintainer or not i'd like to be able to setup triggers so that i'm automatically cc'ed on any bugs matching a simple search query i specify.
The email sent out to people cc'ed when a new bug is opened and unassigned should have a simple links in it when cc'ed to someone who can be assigned bugs: 'Assign to me' that if followed will assign that bug to them without requiring a login.
Of course, it will take a while for the field to be filled in on existing issues, but even having it be possible would be very nice.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/greg%40krypto.org
yet another feature request or two to be lost to a mailing list thread along those lines:
Maintainer or not i'd like to be able to setup triggers so that i'm automatically cc'ed on any bugs matching a simple search query i specify.
Please add that to the meta tracker (if you really want it, rather than just losing it on the mailing list :-)
Implementing it would be quite involved, I think. It should probably go into the saved query feature. Evaluating them on every change would might be expensive, so doing so only regularly (e.g. hourly) would be ok?
The email sent out to people cc'ed when a new bug is opened and unassigned should have a simple links in it when cc'ed to someone who can be assigned bugs: 'Assign to me' that if followed will assign that bug to them without requiring a login.
Unfortunately, this is now defeated by the fear of XSS attacks. If such a link was possible, it would be also possible to embed it into a XSS attack, right?
It would be possible to protect the link with a token, but then, efficient token validation might be tricky. So this would also need to go into the meta tracker.
If you are really interested in these, it would be best to add them as feature requests to roundup itself (since that really is the place where they should be provided):
http://issues.roundup-tracker.org/
[but then, roundup could also use more contributors]
Regards, Martin
Le Thu, 22 Oct 2009 21:47:06 -0700, Brett Cannon a écrit :
- Dropping Stage in favor of some keywords (e.g. 'needs unit test',
'needs docs')
What would it bring? We don't have a very strict process and the current "stage" looks sufficient to me. Saying that unit tests or docs are lacking is part of the review and doesn't need a specific indicator IMO.
Besides, the more keywords there are, the messier it is.
Antoine Pitrou writes:
Besides, the more keywords there are, the messier it is.
That's what I've found in the XEmacs tracker. Keywords are a reasonable way (in the context of the Roundup implementation) to test new classifications before going to the effort of messing with the page templates. But if you don't think "stage" is needed, I'd say drop it entirely rather than demote it to keywords.
Keywords themselves are rather confusing to non-tracker-hackers, anyway. A lot of people seem to think anything that occurs to them should be allowed. That's not true in Roundup, you need to register a keyword before using it.
In the XEmacs tracker I don't allow non-committers to do that. I'm open to changing that policy, but as yet I haven't seen a keyword suggestion from a non-committer that either (1) helps the committers to do their work or (2) seems likely to help users find relevant bugs. The suggestions are always of the form "it would make the interface more complete/consistent." So I'm going to maintain editorial control for now....
Brett> Another summit, another potential time to see if people want to Brett> change anything about the issue tracker.
I have no idea how hard this would be to implement and won't be at the language summit to formally present the idea, but it seems to me that some integration between the issue tracker and Rietveld would be beneficial. If someone attaches a patch to an issue the current next step is essentially a code review without the benefits provided by a code review tool. I'd envision a bit of workflow like this:
* A patch is attached to an issue. * The user clicks the "Create Review" button. (Maybe not all patches require review?) * This generates a review request in Rietveld with all on the nosy list invited as reviewers. (Or should this be a side effect of attaching a patch?) * The "needs review" keyword is added to the selected keywords. * A link to the review request is added as a comment to the issue so other people not on the nosy list can evaluate the patch. * If an updated diff is uploaded the review request would be updated. That might necessitate adding a "Replace Patch" button next to all uploaded patches instead of adding a new one then deleting a previous one.
Skip
skip@pobox.com wrote:
Brett> Another summit, another potential time to see if people want to Brett> change anything about the issue tracker.I have no idea how hard this would be to implement and won't be at the language summit to formally present the idea, but it seems to me that some integration between the issue tracker and Rietveld would be beneficial.
See
http://psf.upfronthosting.co.za/roundup/meta/issue247
Regards, Martin
>> ... it seems to me that some integration between the issue tracker >> and Rietveld would be beneficial.
Martin> See
Martin> http://psf.upfronthosting.co.za/roundup/meta/issue247
Cool. I still haven't used Rietveld for anything, though I am getting comfortable with Review Board and like the tool support for code reviews.
Skip
-
"Martin v. Löwis" -
Antoine Pitrou -
Ben Finney -
Brett Cannon -
Gregory P. Smith -
Nick Coghlan -
skip＠pobox.com -
Stephen J. Turnbull