|| ||Chris Mason <chris.mason-AT-oracle.com> |
|| ||Jeff Putney <jeffrey.putney-AT-gmail.com> |
|| ||Re: Honest timeline for btrfsck |
|| ||Thu, 6 Oct 2011 22:50:50 -0400|
|| ||linux-btrfs <linux-btrfs-AT-vger.kernel.org>|
|| ||Article, Thread
On Thu, Oct 06, 2011 at 10:31:41AM -0500, Jeff Putney 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.
[ Thanks for everyone's comments! ]
Keep in mind that btrfs was released and ran for a long time while
intentionally crashing when we ran out of space. This was a really
important part of our development because we attracted a huge number of
contributors, and some very brave users.
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.
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.
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
to post comments)