Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754245AbbHAAAw (ORCPT ); Fri, 31 Jul 2015 20:00:52 -0400 Received: from mail.phunq.net ([184.71.0.62]:55487 "EHLO starbase.phunq.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752230AbbHAAAv convert rfc822-to-8bit (ORCPT ); Fri, 31 Jul 2015 20:00:51 -0400 From: Daniel Phillips To: David Lang Cc: Rik van Riel , Jan Kara , , Linux Kernel Mailing List , , OGAWA Hirofumi Subject: Re: [FYI] tux3: Core changes Date: Fri, 31 Jul 2015 17:00:43 -0700 User-Agent: Trojita/v0.5-14-g8a2496c; Qt/4.8.6; X11; Linux; Ubuntu 15.04 MIME-Version: 1.0 Message-ID: In-Reply-To: References: <67294911-1776-46b8-916d-0e5642a38725@phunq.net> <20150526070910.GA3307@quack.suse.cz> <20150526090058.GA8024@quack.suse.cz> <5564D60E.6000306@phunq.net> <20150527084138.GD2590@quack.suse.cz> <87a8vtdqfz.fsf@mail.parknet.co.jp> <20150623161247.GP2427@quack.suse.cz> <87k2ueepd6.fsf@mail.parknet.co.jp> <20150709160528.GK2900@quack.suse.cz> <874mklaqbn.fsf@mail.parknet.co.jp> <1981a91e-30a9-43ce-9a05-14aa777e46a5@phunq.net> Organization: tux3.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2467 Lines: 60 On Friday, July 31, 2015 3:27:12 PM PDT, David Lang wrote: > On Fri, 31 Jul 2015, Daniel Phillips wrote: > >> On Friday, July 31, 2015 11:29:51 AM PDT, David Lang wrote: ... > > you weren't asking about any particular feature of Tux, you > were asking if we were still willing to push out stuff that > breaks for users and fix it later. I think you left a key word out of my ask: "theoretical". > Especially for filesystems that can loose the data of whoever > is using it, the answer seems to be a clear no. > > there may be bugs in what's pushed out that we don't know > about. But we don't push out potential data corruption bugs that > we do know about (or think we do) > > so if you think this should be pushed out with this known > corner case that's not handled properly, you have to convince > people that it's _so_ improbable that they shouldn't care about > it. There should also be an onus on the person posing the worry to prove their case beyond a reasonable doubt, which has not been done in case we are discussing here. Note: that is a technical assessment to which a technical response is appropriate. I do think that we should put a cap on this fencing and make a real effort to get Tux3 into mainline. We should at least set a ground rule that a problem should be proved real before it becomes a reason to derail a project in the way that our project has been derailed. Otherwise, it's hard to see what interest is served. OK, lets get back to the program. I accept your assertion that we should convince people that the issue is improbable. To do that, I need a specific issue to address. So far, no such issue has been provided with specificity. Do you see why this is frustrating? Please, community. Give us specific issues to address, or give us some way out of this eternal limbo. Or better, lets go back to the old way of doing things in Linux, which is what got us where we are today. Not this. Note: Hirofumi's email is clear, logical and speaks to the question. This branch of the thread is largely pointless, though it essentially says the same thing in non-technical terms. Perhaps your next response should be to Hirofumi, and perhaps it should be technical. Regards, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/