Re: Refactoring the tracker

2010-05-15 Thread Raphael Geissert
Florian Weimer wrote: > * Raphael Geissert: >> I personally found the OO approach to the generation of the web >> pages really painful. > > I'm open to different suggestions. My experience with web frameworks > is rather limited and does not include any current frameworks. I only know some rando

Re: Refactoring the tracker

2010-05-09 Thread Florian Weimer
* Michael Gilbert: > Along with Raphael's suggestion, perhaps during updates we could > load the new dictionaries into memory concurrently with the old > ones. Then we could compare the two and only act on items that > actually have differences before pushing the new updates. As long as things fi

Re: Refactoring the tracker

2010-05-09 Thread Florian Weimer
* Raphael Geissert: > Florian Weimer wrote: >> Another issue which has gained some significance lately is that the >> package and CVE lists have grown quite a bit, leading to longer and >> longer processing times on soler. I've removed a few unused features >> to speed things up a bit, but it see

Re: Refactoring the tracker

2010-05-07 Thread Michael Gilbert
On Tue, 04 May 2010 21:20:16 -0500 Raphael Geissert wrote: > Florian Weimer wrote: > > Another issue which has gained some significance lately is that the > > package and CVE lists have grown quite a bit, leading to longer and > > longer processing times on soler. I've removed a few unused featur

Re: Refactoring the tracker

2010-05-05 Thread Nico Golde
Hi, * Moritz Muehlenhoff [2010-05-04 21:55]: > On Tue, May 04, 2010 at 08:34:38PM +0200, Florian Weimer wrote: > > I've decided that it's necessary to clean up the mishmash between SQL > > and Python in the tracker code base. As I've mentioned before, there > > are three or four different ways fo

Re: Refactoring the tracker

2010-05-04 Thread Raphael Geissert
Florian Weimer wrote: > Another issue which has gained some significance lately is that the > package and CVE lists have grown quite a bit, leading to longer and > longer processing times on soler. I've removed a few unused features > to speed things up a bit, but it seems that we're at the bare m

Re: Refactoring the tracker

2010-05-04 Thread Michael Gilbert
On Tue, 04 May 2010 21:54:50 +0200, Florian Weimer wrote: > * Michael Gilbert: > > > How about making use of a more standardized set of python features such > > as dictionaries for the database, and possibly storing those to disk > > using pickles > > The actual data is just 44 MB as an SQLite da

Re: Refactoring the tracker

2010-05-04 Thread Florian Weimer
* Michael Gilbert: > How about making use of a more standardized set of python features such > as dictionaries for the database, and possibly storing those to disk > using pickles The actual data is just 44 MB as an SQLite database, so this might work indeed. I had planned to use smaller pickles

Re: Refactoring the tracker

2010-05-04 Thread Moritz Muehlenhoff
On Tue, May 04, 2010 at 08:34:38PM +0200, Florian Weimer wrote: > I've decided that it's necessary to clean up the mishmash between SQL > and Python in the tracker code base. As I've mentioned before, there > are three or four different ways for deciding if a vulnerability is > fixed in a particul

Re: Refactoring the tracker

2010-05-04 Thread Michael Gilbert
On Tue, 04 May 2010 20:34:38 +0200, Florian Weimer wrote: > I've decided that it's necessary to clean up the mishmash between SQL > and Python in the tracker code base. As I've mentioned before, there > are three or four different ways for deciding if a vulnerability is > fixed in a particular pac

Refactoring the tracker

2010-05-04 Thread Florian Weimer
I've decided that it's necessary to clean up the mishmash between SQL and Python in the tracker code base. As I've mentioned before, there are three or four different ways for deciding if a vulnerability is fixed in a particular package version. This makes changing the processing logic and creati