Re: Debbugs: The Next Generation
Note, I already have a database schema. Look at
master/~doogie/debbugs/import.pl.
On Wed, 8 Aug 2001, Matt Zimmerman wrote:
> On Wed, Aug 08, 2001 at 02:07:10PM +1000, Anthony Towns wrote:
>
> > On Tue, Aug 07, 2001 at 11:11:37PM -0400, Matt Zimmerman wrote:
> > > Me: "It's long past time that the BTS had a real database backend. Is
> > > there any way I can help?"
> >
> > You do understand how a jump from "perl + known text backend + working and
> > tested" to "C++ + new SQL backend + important parts yet unimplemented" by
> > someone who hasn't done much with the BTS as it stands isn't going to inspire
> > confidence straight off, right?
</aol>
> > Personally, eg, I find C++ a revolting language, and not one that's
> > particularly well suited to debbugs (where speed isn't particularly critical,
> > and the slowness is due to algorithmic inefficiencies (like reindexing
> > regularly rather than updating them as the database changes; and like having
> > large numbers of files in a signle ext2 directory). Switching from an
> > arch-independent language, to one whose ABI changes incompatibly quite
> > regularly is also something I wouldn't do.
> I chose C++ because it's relatively easy to use C and C++ code from interpreted
> languages, but not to share code written in, say, Perl, with other languages.
> With the current debbugs, there seems to be a choice between using the Perl
> stuff or parsing the files yourself. While munging the text files by hand
> isn't that unappealing, futzing with the database by hand is, so I would prefer
> to share that code.
Those who work on debbugs want an easily maintainable system. C/C++ do not
come to mind as being in that category.
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.
Note, the above can be read as reimplementing a cross-platform, langauge
agnostic, data querying language.
> > But if you or someone else who actually likes C++ is going to maintain the
> > BTS and make sure it works on a day-to-day basis, that could be okay.
Could this be read as you(aj) not wanting to deal with a C++ version of
debbugs? If so, I agree.
> There is some hairy Perl in there, I agree. I've been doing the implementation
> "from the outside in", without worrying too much about debbugs internals apart
> from the file formats.
I've been working with the debbugs code base on and off for around 2 years. I
would rather try to implement it from the outside.
However, having said that, there are lots of little things the code supports,
that isn't documented, and would be overlooked by someone doing it this way.
> > Personally, I'd be inclined towards changing the .log format to be something
> > akin to batched-SMTP and stored in the filesystem (so that it can be
> > "replayed" if the database crashes; and so that the way the bugs logs are
> > displayed can be changed in future).
My goal was to use mbox for .log. Get rid of .report. And only use a
relational database for readonly queries, and not make it the authorative
version of the data.
Reply to: