Hi Martin, Sorry about being so brief, I got a lot of unexpected interruptions and was rushing things. "Martin v. Löwis" wrote:
For starters, free form searches, aggregation and filtering of results.
What is "free form searches" (example)? What is aggregation? What results do you want to filter? (roundup can already filter results quite well)
By free form searches I meant complex queries with more flexible criteria. A real example: "find any issue that has words A and B in juxtaposed in messages, containing words starting with 'url' [ but not ending with 'lib' in title (, unless version >= 3)], where jjlee isn't nosy". Or "issues with less than 5 replies, all from a single user". Lastly, "issues where no Developer is nosy, with messages covering an interval longer than a week". These are useful a few times, but hard to predict and not so recurrent searches, so free form makes more sense than adding support for each combination. By aggregation I meant performing a few disjunct searches and combining them in a result set, eliminating duplication, to process as a unit. Then, add issues A,B and C to that. Free form searches cover this by allowing one to perform a query that gives the result set directly, but combining previous searches sounds more pleasant. And by filtering, I meant refining a set of search results and/or searching over a restricted set of issues, on criteria that are present in them. I.e., I'd like to search for segfault and be given a choice box with the all nosy people in the result set, and exclude or only display issues based choosing one of them. All of the above seems trivial with a database-like interface. I have pretty much emulated them with the current search, the handy CSV results downloads, a text editor and a Python shell.
The web interface is pretty good for handling individual issues, but not so good for adding someone as nosy to lots of issues.
Please consider contributing a mass-update template then, perhaps based on search results, with check boxes to include or exclude individual issues from the mass update.
OK, I saw one of these at http://roundup.sf.net/ and will study and adapt it. But it'll solve the 'commit changes' part of the equation, not the 'select set of issues to change'.
Send emails before they were done :D
Again: what's that?
That's me trying to sound witty after sending the email before finishing it :)
Use a VCS for in-progress activities
Hmm. Why do you need a database copy for that?
I don't, the database if for selecting issues to edit. But I'd like to be able to submit bulk changes, and a (local, D) VCS is how I imagine storing these locally should be done. For rollbacks, merges and that sort of thing, besides being able to save incomplete work to continue later.
Figure out how to serialize and submit the work done locally
Again, don't understand. too brief.
The serialization idea comes from this: one would assemble a 'patch' containing different changes to different issues. It's an extension of the mass-update idea, but for non-uniform changes. The deserialization would either happen through a mass-update interface or by running a script to submit them one by one.
Share results with interested parties off-tracker (e.g., the auto-nosy mentioned up-thread)
The tracker already has auto-assignments based on components.
But no way to share aggregated search results (I've sent some off-list), 'follow' users (i.e., be added as nosy for issues where user A is nosy), auto-add as nosy based on keywords, etc. Someday we could have these nosy features hosted externally, e.g. as an AppEngine app that subscribes to python-bugs and sends alerts to users matching the message (by keyword, performed action, new stage, etc.).
Right now, more efficient searching and aggregation along with some (local, flexible) UI tweaks sum it up.
Efficient in what way?
Having those complex searches in a less convoluted workflow, allowing more work to be done faster and in a less error prone way.
Maybe I can offer a patch for something like PyPI's 'simple' interface?
Please, no. Contribute the interface you want locally instead as a feature for all users of the tracker.
OK, after some more cleaning up I'll work on the mass-update, my local searches and report back. Regards, Daniel