A plan for the kernel Bugzilla

Posted Oct 17, 2022 13:52 UTC (Mon) by taladar (subscriber, #68407)
Parent article: A plan for the kernel Bugzilla

I wonder how many of the developers are overworked because of the email workflow.

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.

Email also is far from ideal for remembering which tasks you still have to work on or for assigning tasks to one of a group of people.

To be honest the whole discussion always feels like the entire kernel development community is just very stuck in their ways and unwilling to attempt changes. And I say that as someone who also largely lives in the terminal for my workflows.

There might also be some fear involved that making the process more accessible will lead to more bug reports.

An off-the-shelf issue tracker might not exactly fit their needs but for such a large community it should be possible to design a software that fits their requirements the way Linus did with git back in the day, 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.

A plan for the kernel Bugzilla

Posted Oct 17, 2022 15:21 UTC (Mon) by Wol (subscriber, #4433) [Link]

> I wonder how many of the developers are overworked because of the email workflow.

> 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.

> Email also is far from ideal for remembering which tasks you still have to work on or for assigning tasks to one of a group of people.

And what sort of replacement can you think of? If you can't visualise a solution, then you're somewhat up a gum tree.

I've always worked for end-user type setups, despite spending my career as a database programmer. My only (short) stint in a software house brought me to the brink of suicide ...

And even though I'm now not officially anything to do with programming/software etc (my job title is Business Analyst) I'm still the goto guy for programming and databases (and I love it). But I don't think there is ANY tool that can reduce the overload when there's just too much work, and not enough time.

The nice thing about my company is, although they want stuff done (don't they all), they recognise that there's only so much you can do, and I have free reign to cherry-pick the projects I want and ignore the rest (mostly :-) It helps, of course, that I tend to cherry pick projects that embody my philosophy of "if the computer can do it, then let it get on with it!" When my projects come off, they reduce everybody else's workload ... (only for different stuff to replace it :-)

So for me, email is ideal. I just lose the projects I don't want in the flood :-)

Cheers,
Wol

A plan for the kernel Bugzilla

Posted Oct 18, 2022 9:10 UTC (Tue) by marcH (subscriber, #57642) [Link] (6 responses)

> 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" :-)

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?