diff options
| author | madduck <madduck@3cfab66f-1918-0410-86b3-c06b76f9a464> | 2006-11-09 15:24:24 +0000 |
|---|---|---|
| committer | madduck <madduck@3cfab66f-1918-0410-86b3-c06b76f9a464> | 2006-11-09 15:24:24 +0000 |
| commit | 86b61328c5611df88d0646f46fdd8a9d1f359ae0 (patch) | |
| tree | 82abe550dd08258a76a7d9a5d1db5b3e13294fc7 /debian/TESTING | |
| parent | 9cddabad86c950e3c152a90130ef91cf11ce7e43 (diff) | |
udpates
Diffstat (limited to 'debian/TESTING')
| -rw-r--r-- | debian/TESTING | 17 |
1 files changed, 15 insertions, 2 deletions
diff --git a/debian/TESTING b/debian/TESTING index 20dc7129..641127aa 100644 --- a/debian/TESTING +++ b/debian/TESTING @@ -1,5 +1,18 @@ -Testing new version of mdadm -============================ +Call for help testing new versions of mdadm +=========================================== + +The problem with being the mdadm maintainer is that it doesn't make any +friends but potentially quite a lot of enemies. Even though it's actually very +unlikely that a new mdadm version causes data loss (mdadm is only the remote +control into the kernel), people seem to exhibit unexpected reactions when +their MD arrays with important data don't want to start anymore. In such +a case, don't panic, don't do anything without understanding the implications, +and consider asking for help. + +That said, I would appreciate if you guys helped me test the latest mdadm +releases a bit more thoroughly. I do extensive tests myself, but as Murphy +would be able to predict, the problem only ever occur on other people's +machines, and I'd much rather fix them sooner than later. The easiest way to test new mdadm packages is by adding my package repository (i386/amd64) to your sources.list file, and configuring the APT pins |