The Linux development process: Is it worth the hassle?

Commit messages and the patch

  1. The sheer amount of people from different backgrounds, different companies, with different motivations and agendas. Massive projects happening within a company’s wall can use other mechanisms to spread information and guarantee accountability. And for Open Source projects, few (if any) are as big, long lived, and touched-by-many as Linux.
  2. Backports: given its size and importance, Linux is in a constant state of forking. Even now in 2020 distributions may add their own fixes on top of a version they deem LTS. And if this occurs less frequently now than in the early 2000, when a non negligible part of Red Hat’s competitive moat was the stabilization fixed it brought to its kernel, that is only because Linux itself started having its own LTS series that distributions can draw from.

Is there a solution?

  1. Git is a source control system, and source control systems naturally want to append into, not rewrite history. However that gets conflated together with the development process both in GitHub, where development and review is centered around git commits, and for plain text Linux developers who develop in their own local git trees, constantly rewriting history. Perhaps we need to break this in two, and allow development and review to happen in separate tools that are more ephemeral in nature and make it easier to move code around. Git would store the results. One good analogy for this is how CSS allowed HTML developers to dissociate presentation from logic. Remember how HTML used to be before CSS? I, for one, am old enough…
  2. As an extension of the above, perhaps patches with line-by-line diff are making everything harder. Could we have a system in which we could describe in a higher level what changes I am making to the code, and deterministically be able to apply those changes somewhere else? For example, I could say “Move function create_foo() before create_bar()” or “add an integer parameter called y as the last parameter of create_bar()”. Even if subsequent changes will add things to the surroundings of that code that would break line-by-line diff, such a system would still be able to apply the changes to a slightly different versions of the code base that suffered modifications. Perhaps I am too naive and this is just impossible, but seeing some mind-boggling advances that GPT-3 is making makes me think that this may be possible any time soon.
  3. Or in a less ambitious take, perhaps there is an intermediate solution where code review process can happen by always appending code. When all parts are happy, then at that point and at that point only, history is rewritten. A much simpler and easier tool can just help the maintainer verify that the changes made are all around reorganization by ensuring that there is no diff against the code that was approved.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store