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 _______________________________________________ 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/archive%40mail-archive.com