[SCM] wiki-content branch, master, updated. 12efc3630e0a7bc6cdf54ae16345a5c44624985e

[Daniel Baumann]

The following commit has been merged in the master branch:
commit 12efc3630e0a7bc6cdf54ae16345a5c44624985e
Author: Daniel Baumann <daniel at debian.org>
Date:   Sat Jan 23 09:02:12 2010 +0100

    Sorting live-initramfs feature page by priority.

diff --git a/devel/live-initramfs/features.mdwn b/devel/live-initramfs/features.mdwn
index d7941fb..833460c 100644
--- a/devel/live-initramfs/features.mdwn
+++ b/devel/live-initramfs/features.mdwn
@@ -1,49 +1,65 @@
 # live-initramfs Features
 
-## Boot methods
+## Priority 1: Core Features
 
-  * Optical media (cd, dvd, bd) and nested images
-  * Mass storage (usb-zip, usb-hdd) and nested images
-  * Network filesystems (nfs, smb/cifs, afs) and nested images
-  * Network protocols (http, ftp, rsync)
-  * Network devices (nbd, aoe, iscsi)
-  * Local filesystems (ext2-4 etc.), as image and plain.
-  * Local storage subsystems (lvm, md, etc.).
-  * Allow to include system completely in initrd.img (like debirf).
-  * Allow tunneling (ssh, openvpn, ike) when network is needed to access the root filesystem.
+### General
+
+  * Synchronise and unify boot parameters
+  * Document stuff properly, both the actual implementation and its customization
+  * Use sane coding style consistently
+
+### Boot Methods
+
+  * Optical media (cd, dvd, bd)
+  * Mass storage (usb-hdd, usb-zip)
 
-## Boot process
+### Boot Process
 
   * One time argument handling (with proper respect of live.conf, also from /live/live.conf)
   * One time function handling
   * Split out late user space to dedicated package (live-initscripts)
   * Distributor specific mode for overloading of functions
   * Release specific compatibility/legacy handling during package build-time
-  * Maybe even integrate mechanism to produce 'targeted' and 'generic' initrd-images, where the targeted only contain the scripts defined.
   * i18n/l10n support during early userspace (gettext, po4a)
+  * Logging with different types of messages (info, warn, error, ...). Depending on the log-level just the according level messages are visible. All boot messages should be logged for later investigation.
+
+## Priority 2: Important Features
+
+### Boot Methods
+
+  * Network filesystems (nfs, smb/cifs)
+  * Local filesystems (ext2-4 etc.), as image and plain
+  * Reimplement persistency from scratch
+
+### Boot Process
+
   * Splash support (plymouth, splashy)
-  * Use initramfs keyb functions, rather than re-implenting wheels
 
-## Features
+## Priority 3: Wishlist
+
+### General
 
-  * Redo persistency from scratch
+  * Optimize sh calls for speed and simplicity
+  * Think about implementing parts of it that are performance critical in C
+  * Fix (almost) whatever is listed in the BTS :)
+
+### Boot Methods
+
+  * Support nested images
+  * Network filesystems (afs)
+  * Network protocols (http, ftp, rsync)
+  * Network devices (nbd, aoe, iscsi)
+  * Local storage subsystems (lvm, md, etc.).
+  * Allow to include system completely in initrd.img (like debirf).
+  * Allow tunneling (ssh, openvpn, ike) when network is needed to access the root filesystem.
+
+### Boot Process
+
+  * Maybe even integrate mechanism to produce 'targeted' and 'generic' initrd-images, where the targeted only contain the scripts defined.
+  * Use initramfs keyb functions, rather than re-implenting wheels
   * Allow to clear persistency (by reformating the partition) through live-initramfs (for the firmware trick: factory reset).
   * cryptsetup and rsyncrypto (or something similar) for the persistency layer
   * persistency layer on network shares, global and per user.
   * Improved toram (awk progressbar or something like that)
   * Redo login manager support (kdm, gdm, nodm, plain startx on tty1)
   * Make sure it works with suspend-to-disk.
-  * Logging with different types of messages (info, warn, error, ...). Depending on the log-level just the according level messages are visible. All boot messages should be logged for later investigation.
-
-## Bugs
-
-  * (Almost) whatever is listed in the BTS :)
-
-## General
-
-  * Document stuff properly, both the actual implementation and its customization
-  * Use sane coding style consistently
-  * Optimize sh calls for speed and simplicity
-  * Think about implementing parts of it that are performance critical in C
-  * Drop unused, overly complicated features
-  * Synchronise and unify boot parameters

-- 
wiki-content