> 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. :-) . Thanks for all the effort --jeff -- 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
