Warrior Tang (tangaroa) wrote,
Warrior Tang
tangaroa

Quick thoughts on the Linux patch workflow

Patches for a software product flow like this:

(Core developer) --> (Distro) --> (Sub-Distro)

Example:

Linux Kernel --> Debian --> Ubuntu --> Mint

The core developer produces a product and incrementally improves it. Each distributor may have its own set of patches to the product. The sub-distributors take the patched product and may patch it further.

There are many, many, many core developers and it can be a lot of work to catalogue them all and keep up to date with their development. Sub-distros are based on the distros that already did this work.

If a sub-distro does not keep up to date with its upstream distro's patches, any value its uniqueness may have added to the Linux world is quickly offset by its obsolescence. Consider "Bob's OS, based on Red Hat 6.2!"


Problems:

* If distros are lazy, the different software products offered by different distros may all claim core version number "1.2.3". This leads to confusion when the behaviour of "version 1.2.3" is not as documented. The patching vendor should change the version number to be like "1.2.3.rh-6", indicating who the vendor is and how many different patched versions of the product the vendor has released.
* If distros fail to keep up to date with core product releases, sub-distros may go around them and release the later versioned core product themselves. The sub-distro then risks failing to keep up with the parent distro's patches if the parent catches up and continues patching.
* If a distro in the middle of the chain slows development, those further down have to take over their work or suffer the same slowdown.
* A distro may not notice when core development obsoletes its patches.



Patches will also flow backwards from users, by the vendor's development of ideas offered by users and by direct development by users who are also coders.

(Core developer) --> (Distro) --> (Sub-Distro) <-- (Customer complaints and ideas)

The distro may then send the changes upstream. When a patch reaches the core developers, it gets integrated into the main product. Many Linux users are savvy enough to go straight to the core developers themselves.


Problems:

* Patches produced by distros and independant developers are sometimes not up to the standards of the core developers and are not integrated into the core product.
* Distros have an incentive to keep their patches from their upstream in order to distinguish themselves from their competition. The GPL helps, but it takes work to dig through a distro's source and see if they patched anything.


It is possible for a sub-distro to take patches for different products from two different parent distros. A cause for this occurring would be if the second distro's patches had a good reputation. At this point the product is forked, as that distro has become a second core developer.




Imagine something like Distrowatch with a graphical map of distros and the distros that they are based on, a way to pull up lists of packages that differ between distros and their upstream, and a way to pull up the differences. It would be a visualization of the Linux software ecosystem. I'm not sure how useful it would be, but it would be cool to see.



I once diffed my distro's kernel against the official kernel and there were so many changes that I wondered if anyone was keeping track of them all.
  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

  • 0 comments