[FFmpeg-devel] [RFC] Some ideas for roundup

[Luca Barbato]

On 12/21/2010 01:03 AM, Michael Niedermayer wrote:
> On Mon, Dec 20, 2010 at 03:11:37PM +0100, Luca Barbato wrote:
>> On 12/20/2010 12:39 PM, Stefano Sabatini wrote:
>>> Topic or tag is quite indifferent to me.
>>
>> For roundup the semantics and usage is the same as the Tag you see in
>> other social network, just the name is more precise.
>>
>>> Other issues:
>>>
>>> * it would be nice to show the creation date rather than the activity,
>>>   older issues should be displayed on top of the list by default so
>>>   that they will get more attention
>>
>> Prepare the custom query and I'll add it.
>>
> 
>>> * what about to list all the bugs on the same page? It is quite
>>>   annoying to browse through many pages, having all the bugs on the
>>>   same page would be much simpler.
>>
>> You do not want that, the browser would crawl and the server would work
>> more for no use.
> 
> listing all bugs on a single page is easy in a server friendly way.
> cronjob
> about browser, no comment

Feel free to try

http://roundup.ffmpeg.org/issue?@sort=-activity&@search_text=&@columns=id,activity,title,creator,assignedto,status&@dispname=Show
All&@group=priority&@filter=status&@pagesize=50000&@startwith=0&status=-1,1,2

and tell me back. Everybody is free to hammer the server, if it breaks
I'll have to restrict the custom queries accordingly. The defaults could
be changed easily but should remain sane.

>>> * issue filtering: for example I might want to see only the issues
>>>   related to topic1+topic2-topic3 which are older than two
>>>   months. Would be this possible?
>>
>> Intersection and union operator aren't exposed by the current query
>> builder, still I'd like to think a bit more before adding more load to
>> the server. (and maybe work with upstream to get the orm use the db
>> better...)
> 
> A pretty naive implementation of this should with the few thousand issues we
> have easily allow thousands of such querries on a 486 33mhz per second
> lucky there are a few bloat layers and a database

a non performance impaired db layout would not have problems with that.
Keep in mind that I had to nuke the assign combo box since the developer
role is a ... free-form string and I'm afraid topics is done the same
way... So if you play with it you have to:

- fetch all the entries from the db (with or w/out natural joins with
other tables)

- iterate over them

- stringcompare to get the topic groups

- nested loop over them to get something.

- format

- show

lu

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero