On Thu, Oct 6, 2011 at 10:31 AM, Jeff Putney <jeffrey.put...@gmail.com> wrote: >> No, in this case it means we're confident it will get rolled out. > > On Aug 18th confidence was high enough to declare a possible release > that very day. This confidence turned into 7 weeks of silence > followed by another 2 week estimate. > > These confident declarations are why things like mniederle's > btrfs_rescue are considered 'interim' and not worth building on. Had > this confidence of imminent release not been the prevalent message for > the last year, others would have stepped in to fill the void. > >> I've given a number of hard dates recently and I'd prefer to show up >> with the code instead. I don't think it makes sense to put a partial >> implementation out there, we'll just have a bunch of people reporting >> problems that I know exist. >> >> -chris >> > > This strategy of 'Lone Wolfing it' has delayed the release by a year. > Either you are flying solo because you think that you can make more > meaningful progress without the involvement of the btrfs community, or > you are willing to forfeit the contributions of the community in order > to not have to listen to any complaints. > > The other problem of this flying solo plan, is that you are making the > assumption that the problems you know about are more significant than > the problems you are unaware of and could be flushed out with more > eyes on the code. The longer you delay the release of the source, the > longer it will be until confidence can be generated that major issues > have been resolved. > > http://en.wikipedia.org/wiki/Release_early,_release_often > -- > 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 >
The problem with this is that people naturally look for a fsck tool when something bad goes wrong. Something as important as a fsck utility shouldn't be released (unofficially or officially) half baked. It can irreparably destroy a filesystem which could've otherwise been repaired with a fully functional fsck. I think Chris is trying to prevent that from happening. Perhaps Chris can set up a private developer repo and ask for help from redhat, fujitsu, etc..? -- 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
