Next steps for kernel workflow improvement

Posted Nov 3, 2019 21:14 UTC (Sun) by rodgerd (guest, #58896)
In reply to: Next steps for kernel workflow improvement by logang
Parent article: Next steps for kernel workflow improvement

A lot of what you're describing sounds like the way Fossil works, integrating things like the issue tracker with the source code management: https://fossil-scm.org/home/doc/trunk/www/index.wiki

It's a pity Fossil isn't better-known; they already seem to have solved a lot of these problems.

Next steps for kernel workflow improvement

Posted Nov 4, 2019 14:17 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

From what little interaction I've done with Fossil, there seem to be some intra-version incompatibilities with the database format and the tools (feel free to correct me; I've not interacted with Fossil much beyond cloning sqlite itself). The saga documented for getting a Git repository of sqlite is quite involved[1]. I value stability of source code checkouts very highly.

For those curious, I care because we vendor sqlite which is based on using git repositories for patch tracking before we import the code and then enforce that all changes for the vendoring process are tracked in that repository. Inb4 "vendoring is bad": there's an option to use an existing sqlite, but…Windows.

[1]https://repo.or.cz/sqlite-export.git

Next steps for kernel workflow improvement

Posted Nov 4, 2019 17:26 UTC (Mon) by logang (subscriber, #127618) [Link]

I took a look at fossil's documentation and it really does not have the features I'm suggesting. In fact it uses a completely different model where all repos for a project tend to be synced together instead of being independent and being push/pull (or send-email/am). More over they don't have features like review or features that overlap with what people use their mail clients for (which is what I'm advocating).

Frankly, I think the fossil model is not useful for most open source projects. They don't really have a convincing story for drive-by contribution nor scaling a community. And they pretty much state out right that it would not be suitable for the kernel development model:

>The Linux kernel has a far bigger developer community than that of SQLite: there are thousands and thousands of contributors to Linux, most of whom do not know each others names. These thousands are responsible for producing roughly 89⨉ more code than is in SQLite. (10.7 MLOC vs. 0.12 MLOC according to SLOCCount.) The Linux kernel and its development process were already uncommonly large back in 2005 when Git was designed, specifically to support the consequences of having such a large set of developers working on such a large code base.

>95% of the code in SQLite comes from just four programmers, and 64% of it is from the lead developer alone. The SQLite developers know each other well and interact daily. Fossil was designed for this development model.