On 10/07/2011 09:40 AM, Jeff Putney wrote: >> For fsck, even the stuff I have here does have a way to go before it is >> at the level of an e2fsck or xfs_repair. But I do want to make sure >> that I'm surprised by any bugs before I send it out, and that's just not >> the case today. The release has been delayed because I've alternated >> between a few different ways of repairing, and because I got distracted >> by some important features in the kernel. > > I think there is a major difference between touching up a few bugs > before you release the code, and experimenting with a bunch of > different ways of repairing before you release the code. I know I for > one would get as much value out of reading the code for the strategies > you abandoned as I would get from reading the final code, but I don't > know if having those branches in the main repo would have any value > for the project as a whole. > > As the current solution goes, I'd just like to see a stake in the > ground for some sort of process to move away from the one man army > approach, should distractions etc continue. Given the latest 2 week > estimate, something along the lines of, in 4 or 6 weeks, if it still > isn't 'ready', code will start to be released. > > >> That's how software goes sometimes, and I'll take the criticism because >> it hasn't gone as well as it should have. But, I can't stress enough how >> much I appreciate everyone's contributions and interest in btrfs. >> >> -chris > > I'm only criticizing the decision to not release the source, in > particular given the delays. We all have our priorities and > distractions, and s**t happens. (Part of why I'd argue against the > flying solo strategy.) But, I really do appreciate all the stuff > you've built, which is part of why I am so keen on reading it. :-) . >
The problem is people won't just read it, they will use it. I wrote a basic repair tool for a user in Fedora who seemed to have a very specific kind of corruption, and earlier this week almost a month after my initial repair tool I had to write another tool to go in and just pull all his data off his disk because a bug in my repair tool made his fs _WORSE_, to the point I'm not sure I can fix it. Fsck has the potential to make any users problems worse, and given the increasing number of people putting production systems on btrfs with no backups the idea of releasing a unpolished and not fully tested fsck into the world is terrifying, and would likely cause long term "I heard that file system's fsck tool eats babies" sort of reputation. Release early and release often is nice for web browsers and desktop environments, it's not so nice with things that could result in data loss, especially when our user base is growing in leaps and bounds and aren't necessarily informed enough on the dangers of using an file system that's still under heavy development. Thanks, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
