mdadm (3.4-2) unstable; urgency=low

  * Reneable incremental assembly
  * Rely on udev to assemble incremental arrays
  * In environments with systemd rely on mdadm-last-resort@.timer|.service
    units to activate degrated raids
  * In environments initramfs-tools initrd (no systemd) add local-block
    script to do the same after 2/3rds of root delay iteration
  * Drop local-top initramfs script
  * Drop dependency on initscripts package
  * Drop INITRDSTART support
  * Drop mdadm-raid init script
  * Drop ancient preinst
  * In mdadm.init remove dependency on mdadm-raid
  * In mdadm.init check, and bail out running in a container
  * In mdadm.config drop mdadm/autostart logic
  * Drop CREATE stanzas from mkconf and don't include them in the
    initramfs. The generated defaults, are the compiled-in defaults. And
    the current one generates warnings when running mdadm in the
    initramfs, as there is no passwd|group files to resolve root/disk
    uid/gid. Closes: 717609
  * Adapt changes and formatting of initramfs hook from Ubuntu
  * Bump standards version to 3.9.7, no changes required
  * Fix copyright-refers-to-symlink-license
  * Closes: #781172, #796624, #769201, #813335, #632401, #804973, #714155,
    #770002, #737132, #675452, #726390, #813637, #814036.

# imported from the archive

1 files changed, 29 insertions, 0 deletions

diff --git a/debian/TODO b/debian/TODO
new file mode 100644
index 00000000..eb3299e0
--- /dev/null
+++ b/debian/TODO
@@ -0,0 +1,29 @@
+debian mdadm TODO list
+======================
+
+- version-1 is a nightmare. E.g. on partitionable arrays, with / on
+  /dev/md_d0p3, mdadm -Es ignores /dev/md_d0 and just uses the name, so
+  /dev/md/<arrayname>.
+- figure out something about device names.
+- (better) udev integration
+
+- check whether mdadm.conf and system are consistent during initramfs creation
+  and fail otherwise (#381303).
+- add code to compare existing and expected configuration, after standardising
+  the files. In most cases, we'll have to answer DUNNO as to whether the
+  existing configuration file is okay, but I guess in some cases we can
+  determine that the configuration is okay. A conservative approach would be
+  beneficial to the user. Not sure if it's worth the effort though.
+- one nice^W important thing would be to check device names and UUIDs at least.
+
+- verify operation without udev
+  - udev removed before mdadm installed
+  - udev removed after mdadm installed
+
+- more granular handling of init.d starts/stops, don't force all arrays to be
+  started.
+- let user specify when to start/stop which array (#398310).
+- also only stop those array we started; this can be easily done with
+  sentinels in $STATEDIR
+
+- manage DAEMON_OPTIONS with debconf