Hi! I was just stumblinmg over this bugreport, and must say I am surprised at the logic here - the ntfs3 module does not conflict with existing filesystem drivers (such as ntfs-3g), so existing systems shouldn't be negatively affected as they would continue to either fail to mount or use ntfs-3g, if installed.
also, the logic of keeping it out is very flawed, namely that the feature is new. but the code in question existed for a long time outside the kernel, so arguing there might possibly, potentially, maybe be some problems in the code (that haven't surfaced in the half a year since the release) is very strange. while I appreciate that the kernel package maintainers try to keep dangerous or broken modules disabled, I think doing so based on zero actual evidence is going to far, especially given that other broken modules are enabled (e.g. ufs, which does get used by default and can eat ufs filesystems for breakfast). the only actual evidence so far is that there is no working fsck - well, the same argument could be used to keep btrfs out of debian. I would have understood this decision if the ntfs3 module conflicted with the existing ntfs or ntfs-3g drivers, but it doesn't. please reconsider your decision - thanks!
