From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1422661AbbISRrj (ORCPT ); Sat, 19 Sep 2015 13:47:39 -0400 Received: from h1446028.stratoserver.net ([85.214.92.142]:35256 "EHLO mail.ahsoftware.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755927AbbISRrg (ORCPT ); Sat, 19 Sep 2015 13:47:36 -0400 Subject: Re: First kernel patch (optimization) To: "Theodore Ts'o" , Greg KH , Josh Boyer , Eric Curtin , Austin S Hemmelgarn , Steve Calfee , Valentina Manea , Shuah Khan , USB list , Kernel development list References: <55F95671.6060405@gmail.com> <20150916132426.GA7420@kroah.com> <20150916164031.GH7394@thunk.org> <20150918031251.GA30905@thunk.org> <20150918074248.GA10792@kroah.com> <20150919022624.GB2921@thunk.org> <20150919051827.GB17114@kroah.com> <55FD5A76.1020603@ahsoftware.de> <20150919142219.GF2921@thunk.org> From: Alexander Holler Message-ID: <55FD9FAA.3070401@ahsoftware.de> Date: Sat, 19 Sep 2015 19:47:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150919142219.GF2921@thunk.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 19.09.2015 um 16:22 schrieb Theodore Ts'o: > On Sat, Sep 19, 2015 at 02:52:06PM +0200, Alexander Holler wrote: >> >> I've recently posted a proof of concept for wiping files, or in other words >> to really delete files, And it was a disaster because if someone posts >> imperfect pathhes on this list, people have fun trying to eat you (because >> they seem bored or whatever). > > People gave you feedback on how what would be necessary to make the > patch acceptable, and you rejected the advice complaining that it > would take you months of "unpaid time". You were then complaining > that the people who gave you feedback wouldn't fix the patch for you, > and that you threatened that if we didn't integrate your racy patch > into the core VFS, you would go switch to FreeBSD. Sorry, but I can happily live without feedback like "charming". I've complained about the requirement to post perfect patches without even the promise that they will ever have a chance to end up in the kernel. But where should someone get such an OK for an idea without the possibility to post preliminary patches without earning insulting comments? Anyway, I've accepted that I'm the error here which is why I almost don't post any patches here anymore. >> Even posting perfect patches is a game, because there exists always a space, >> newline or variable name which might be used to start annoying discussions. > > Trust me, the issues with your patch went *way* beyond extra spaces or > newlines. It was (and is, imho) a working proof of concept. I've posted the patch to describe the idea, and NOT as a perfect patch ready for inclusion. I'm fully aware that there are million reasons why some parts of a file might not be deleted, but that is a matter how you describe the functionality. And the concept works imho for many use cases. At least much, much, much better than just nothing. But obviously, one of biggest failures one can do, is to post imperfect patches on this list. Regardless how you describe or mark them (mine had a RFC and WIP in front of), people will use every small detail against you, in order to have something to criticise or to make some fun of. >> So, there is no reason to wonder about the lack of such tasks. > > Greg was specifically looking for patches that could be done in a > weekend. Sorry, I've missed that detail. So maybe create a tracker for such weekend-tasks. > If you want to raise the argument that we should lower the standards > for accepting patches so that more patches can accomplished within a > weekend's worth of work, we can have that discussion --- but I'm not > sure it will have the end result that you are hoping for. No. I don't want to lower the standards. Maybe in regard to silly style stuff, but not in regard to code quality (and I mean real bugs like races, deadlocks or such, and not if a line has more than 80 characters). I would have liked some comments like "good or bad idea" but this list is imho the wrong place to search for such useful comments. I haven't searched for comments on the code, as I was FULLY aware that the code is ugly and NOT ready for inclusion), Alexander Holler