[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110607173042.GB30037@thunk.org>
Date: Tue, 7 Jun 2011 13:30:42 -0400
From: Ted Ts'o <tytso@....edu>
To: Sunil Mushran <sunil.mushran@...cle.com>
Cc: "Amir G." <amir73il@...rs.sourceforge.net>,
Josef Bacik <josef@...hat.com>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH RFC 00/30] Ext4 snapshots - core patches
On Tue, Jun 07, 2011 at 10:14:27AM -0700, Sunil Mushran wrote:
> On 06/07/2011 09:46 AM, Amir G. wrote:
> >I understand the bitterness in btrfs community regarding ext4 snapshot
> >feature. You might say the same things about ext4 64bit feature.
> >I think it is not up to us to decide how it rolls. it's the users
> >and companies involved that dictate where the development happens.
>
> Bitterness is not the issue. The issue is what happens when your
> _patron_ has had enough of the project and decides to stop funding.
Yep. On the other hand, the question is that if you move too slowly,
the patron is just as likely to find another solution to his/her
business problems. Sometimes perfect is the enemy of the good, and
the best technology is not necesssarily what carries the day.
Practical issues of what is available and what works "good enough" are
just as important, if not more so.
The philosophical questions have been discussed before in the "Worse
is Better" dialectic. See: http://dreamsongs.com/WorseIsBetter.html
Or, this set of slides by the same author, "Models of Software
Acceptance: How Winners Win": http://dreamsongs.com/Files/AcceptanceModels.pdf
Back to solid ground --- I'm not going to insist on perfection, but at
the same time, the maintenance burden is something that has to be
acceptable, and there needs to be plan towards making it better. If I
thought Amir was going to disappear the moment the snapshot patches
got accepted, there's no way I'd be accepting them.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists