On Sunday 05 October 2008 08:09, Adrian Bunk wrote: > "accelerate its development and will broaden its developer base" is not > about users/testers but about people doing code development. > > For people wanting to try WIP code you don't need it in mainline. But it saves time for the user, who does not have to run around chasing links, carefully checking for a kernel match, downloading, patching, building and installing a single purpose kernel, and bringing it up on a machine that would probably have only required one click on the new filesystem option otherwise. The considerable time thus saved can be invested profitably in running test cases and filing bug reports. > Stable kernels will anyway usually contain months old code of the > WIP filesystem that is not usable for testing, so for any meaningful > testing you will still have to follow the btrfs tree and not mainline. True, but the trick here is getting started. It is much easier to justify the effort of going out and getting the latest patch if one knows from experience that it basically already works. > This is not meant as a statement on the quality of ext4 or btrfs, or any > comparison of the development times of ext4 and btrfs, but for ext4 the > advantages Andrew thinks would happen with an early btrfs merge do not > seem to have happened. Are you sure about that? I see 33 messages on linux-ext4 yesterday, from a broad range of contributors. Versus eight from a much narrower range of contributors, Oct 4 a year ago. There is little question that an early merge helps both developers and users employ their time more efficiently, once a project is past the point where we wonder about its value and/or viability. In my opinion, Btrfs clearly has both. Particularly because we need a way to stem the loss of mindshare to ZFS in the storage space, which is significant at the moment. And Btrfs is closest to the finish line in that regard. It needs all the help it can get. Regards, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
