Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Chris Mason <chris.mason <at> oracle.com>
Subject: Re: Honest timeline for btrfsck
Newsgroups: gmane.comp.file-systems.btrfs
Date: Friday 7th October 2011 02:50:50 UTC (over 5 years ago)
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.
> 
> http://en.wikipedia.org/wiki/Release_early,_release_often

[ 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.

-chris

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
CD: 2ms