Disk Images and Version Control

Michael Stone michael at laptop.org
Tue Apr 22 01:45:21 EDT 2008

Dear devel,

Our builds are nothing more than specially-formatted Unix filesystems.

  Q: What useful purpose is served by regenerating these filesystems
     from scratch every time we want to change them?

  A: We maintain an explanation of where the filesystem came from
     encoded in the recipe used to create it.

It seems to me that version control systems and shells are the best
tools yet invented for comprehending filesystems and for changing them
in controlled ways.

Could we actually build our disk images from authoritative copies of
our filesystem tree which are wholly maintained in a
version-controlled repository (along with export scripts, tests,
source materials, release notes, defect markers, and other miscellanea)? 


 We might

 * achieve a long-sought "interactive" (as opposed to
   "batch-processing") build maintenance style. 
 * be able to Patch The Build simply by emailing the build-maintenance
   list with our proposed change. 

 * be able to insist on public review of changes to the build

 * maintain confidence in our ability to comprehend and incorporate
   changes made by third parties to the build

 * reduce the need learn RPM packaging techniques in order to
   contribute to the build production process

 * achieve better "blame" support since we would know whose changes
   _actually_ broke the build.

 * be able to more easily bisect a build stream looking for the change
   that introduced a bug

 * ease the process of contributing and maintaining test cases and
   test scripts, automated or not


 We would need to:

 * improve our testing process to detect and cope with conflicting
   changes to generated files like package databases

 * provide root access on some Linux host(s)  (or take great care with
   fakeroot / qemu configuration) to allow others to work on the 
   filesystem without screwing up file ownership and permissions

 * work hard to ensure a consistently high level of quality in our
   release branches by refusing to accept patches with inadequate
   provenance or which bundle unrelated changes.



More information about the Devel mailing list