Message-ID: <55FD9FAA.3070401@ahsoftware.de>
Date:	Sat, 19 Sep 2015 19:47:22 +0200
From:	Alexander Holler <holler@...oftware.de>
To:	Theodore Ts'o <tytso@....edu>,
	Greg KH <gregkh@...uxfoundation.org>,
	Josh Boyer <jwboyer@...oraproject.org>,
	Eric Curtin <ericcurtin17@...il.com>,
	Austin S Hemmelgarn <ahferroin7@...il.com>,
	Steve Calfee <stevecalfee@...il.com>,
	Valentina Manea <valentina.manea.m@...il.com>,
	Shuah Khan <shuah.kh@...sung.com>,
	USB list <linux-usb@...r.kernel.org>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: First kernel patch (optimization)

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists