|
|
Subscribe / Log in / New account

A plan for the kernel Bugzilla

A plan for the kernel Bugzilla

Posted Oct 18, 2022 9:10 UTC (Tue) by marcH (subscriber, #57642)
In reply to: A plan for the kernel Bugzilla by taladar
Parent article: A plan for the kernel Bugzilla

> Emails are useful for many things but keeping information about one topic separate from information about another so you can still easily find it in the future is certainly not one of them.

> e.g. have something with an API that can be used from various automation tools and also with a web interface to use manually and with email notifications for the mailing lists including exactly the information the members of that mailing list need

You mean something like a... bug tracker?

Unfortunately the kernel community has proven to be permanently allergic to anything relying on a database - which they typically call a "web-based tool". While less known, this allergy could be even stronger than the addiction to email - which they use like the entire rest of the world uses a database.

"When all you have is a hammer, everything looks a nail". It's very funny to observe what happens when you apply this to... database people: you end up with version control implemented by a database... of course!
https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-gi...

The "development by email community": a more accurate name than the "kernel community" :-)


to post comments

A plan for the kernel Bugzilla

Posted Oct 18, 2022 10:17 UTC (Tue) by Wol (subscriber, #4433) [Link] (5 responses)

Coming from the Pick world, I look at git and think "it's a database". It's a key:value store, which is certainly the internal abstract model of Oracle, and probably most other relational databases ...

The problem is, imnsho, that too many people don't internalise that an RDBMS is only a small subset of the assorted DBMSs out there, pretty much any of which would be a much better fit to the problem space than an RDBMS.

(After all, isn't a file system just a sort of hierarchical database, etc etc.)

It shouldn't be TOO hard for someone to write an issue tracker that uses git as its back end. In fact, I seem to remember hearing its been done ... it just needs someone with the mindset "not all databases are RDBMSs".

Cheers,
Wol

A plan for the kernel Bugzilla

Posted Oct 18, 2022 11:18 UTC (Tue) by rschroev (subscriber, #4164) [Link] (1 responses)

Git is not just any key:value store though: the key is a hash of the value. Git is a form of content-addressable storage. That makes it pretty well suited for source code control, but much less suited as a general purpose database. Though I guess it can be used as one of you try hard enough to work around the limitations.

A plan for the kernel Bugzilla

Posted Oct 18, 2022 12:47 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

The `refs/` hierarchy works well as an arbitrary key into the content store. Given the perf attention that it's gotten lately, it works pretty well. Our robot has something like 680k refs into over 110 repositories it watches, 600k of which are stored in `packed-refs`. Something could definitely be built through that lens.

A plan for the kernel Bugzilla

Posted Oct 18, 2022 12:50 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (2 responses)

It's been plenty of times before. The problem usually comes down to how to allow arbitrary issue submission, commenting, notification tracking, etc. in a way that doesn't invite spam, have massive GDPR/privacy issues, and handles embargoes or otherwise "secret" issue submissions.

While Git might be a fine storage for such things, it is a terrible *interface* for them.

A plan for the kernel Bugzilla

Posted Oct 18, 2022 14:57 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

I've just been reading a bit about Google BigCloud. It sounds HORRIBLE as a database. It's key-value WITH NO INDICES. As soon as you add indices on arbitrary fields within it (is that what git /refs does?) it becomes *much* more tractable.

Looking at FOSSIL I'd say sqlite makes a terrible bug tracker. But with FOSSIL as the interface it's probably very good. All we need is the FOSSIL interface using git as the datastore instead of sqlite :-)

(And isn't "pure" git rubbish as a source code management system? It's all the - is it called "porcelain"? - on top of the key:value store that makes it great.)

Cheers,
Wol

A plan for the kernel Bugzilla

Posted Oct 19, 2022 11:31 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

> is that what git /refs does?

`git refs` lets you give names to specific objects. If you make a commit while the `HEAD` ref points to one (called a "symbolic ref") under the `refs/heads/` "special prefix", it will be updated to the new commit. I'm not sure I would call them indexes though. `tree` objects might work?


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds