[Python-Dev] Tracker archeology

[Daniel (ajax) Diniz]

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