Re: Debbugs: The Next Generation
On Wed, 8 Aug 2001, Anthony Towns wrote:
> In particular, efficiently getting a list of bugs by some particular
> selection mechanism "all RC bugs", "all bugs related to source package
> <foo>" or whatever, pretty much requires you to hack around the C++
> or SQL stuff.
My test url(see the other email) can do most of what the current web frontend
needs, in addition to more features, using SQL.
> Doing regular database dumps seems likely to be pretty expensive. The
> debbugs archive is currently 2GB, while the active database is just under
> 1GB. By contrast, the twice-daily backups of the package pool database
> on ftp-master is 16MB of SQL. debbugs gets a lot more activity than the
> pool database too, so probably has a lot more chances to trip over any
> bugs in postgresql.
Also, the pool database has serial write access(once a day when katie runs).
Debbugs has semi-random write access, every 15 minutes.
Debbugs also has random read access, while the pool database is seldom
read(and only be developers at that).
> > Those who work on debbugs want an easily maintainable system. C/C++ do not
> > come to mind as being in that category.
>
> Nor does the perl debbugs is currently written in, though.
But if something does go wrong, I find it easier to fix it when it is in
perl(let's not talk about my other language favorite).
>
> > The proper way to do this, is to have a low-level(read c/c++) library that
> > does the absolute bare minimum to store the data in some kind of back end.
> > Then, the logic can be implemented in whatever language is desired.
>
> And to get the data out of that backend efficiently. "Unfortunately",
> you have to know basically everything about your original query in order
> to optimise that at all well. You can't write a "backend interface" and
> assume you'll be able to treat it independtly of the frontend for debbugs.
I had this same discussion at the contract job I was at for 6 months. You
either make an abstract interface, but have no fast way to get at bulk amounts
of the data, or you end up using a single interface, to make it fast.
> I don't want to deal with C++ at all. I'd be quite happy if someone
> else was handling debbugs to my satisfaction and I didn't have to have
> anything to do with it, though.
Maybe debbugs is now the new dpkg, with regard to maintainer disappearances?
k
Reply to: