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. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

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

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....

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