On Wed, 7 Oct 2009, Martin Ågren <martin.ag...@gmail.com> wrote: > I believe one of us misread Russell. :) I thought he meant "While I > understand that you'll be crapped on if a kernel upload eats data, I > think it would be ok to ...". As I read it, he's not expecting them to > do anything *more* than they already do, just to relax the protection > argument a little when it comes to people who are already aiming at > their feet.
Yes. Also anyone who really wants their data to be safe won't use Unstable anyway. BTRFS is a little different to most kernel features, it is significant (both in terms of potential benefits and changes), it has a high profile, and it needs a lot of testing. I would not consider asking the kernel team to do anything special for a random device driver or anything else of similar scope. But it has been pointed out a few times (including a couple of private messages) that experimental has what I desire (thanks for the advice everyone). Now I've discovered that firmware-linux-nonfree doesn't seem to be available so I can't use my e100 Ethernet ports (which are essential for the test machine in question). On Wed, 7 Oct 2009, Alexey Salmin <alexey.sal...@gmail.com> wrote: > I think it's reasonable for package maintainers to check compatibility > with the kernel from the > distribution they upload package to. Especialy here when package is > newer then kernel driver. > It's of course harder to supervise the situation when kernel pass > ahead of user-space packages > but it's also possible. In general I agree that user-space tools should not be uploaded until there is a kernel that can work with them. The fact that I made a filesystem with mkfs.btrfs and can't mount it is obviously not ideal. Of course with this type of change if the upload of the btrfs-tools had been delayed so that the kernel got in first then we would STILL have had the same situation (I believe that there was neither forward nor backward compatibility). -- russ...@coker.com.au http://etbe.coker.com.au/ My Main Blog http://doc.coker.com.au/ My Documents Blog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
