public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alexander Holler <holler@ahsoftware.de>
To: "Theodore Ts'o" <tytso@mit.edu>,
	Greg KH <gregkh@linuxfoundation.org>,
	Josh Boyer <jwboyer@fedoraproject.org>,
	Eric Curtin <ericcurtin17@gmail.com>,
	Austin S Hemmelgarn <ahferroin7@gmail.com>,
	Steve Calfee <stevecalfee@gmail.com>,
	Valentina Manea <valentina.manea.m@gmail.com>,
	Shuah Khan <shuah.kh@samsung.com>,
	USB list <linux-usb@vger.kernel.org>,
	Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: First kernel patch (optimization)
Date: Sat, 19 Sep 2015 19:47:22 +0200	[thread overview]
Message-ID: <55FD9FAA.3070401@ahsoftware.de> (raw)
In-Reply-To: <20150919142219.GF2921@thunk.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

  reply	other threads:[~2015-09-19 17:47 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-15 19:53 First kernel patch (optimization) Eric Curtin
2015-09-15 20:11 ` Felipe Balbi
2015-09-16  0:09 ` Steve Calfee
2015-09-16 11:45   ` Austin S Hemmelgarn
2015-09-16 12:56     ` David Laight
2015-09-17  1:49       ` Jaime Arrocha
2015-09-17  8:45         ` David Laight
2015-09-16 13:24     ` Greg KH
2015-09-16 16:03       ` Eric Curtin
2015-09-16 16:40         ` Theodore Ts'o
2015-09-16 17:24           ` Raymond Jennings
2015-09-16 17:26           ` Josh Boyer
2015-09-18  3:12             ` Theodore Ts'o
2015-09-18  7:42               ` Greg KH
2015-09-18  9:31                 ` Raymond Jennings
2015-09-18 19:08                   ` Austin S Hemmelgarn
2015-09-19  2:26                 ` Theodore Ts'o
2015-09-19  4:22                   ` Sudip Mukherjee
2015-09-19  5:18                   ` Greg KH
2015-09-19 12:20                     ` Theodore Ts'o
2015-09-19 12:52                     ` Alexander Holler
2015-09-19 14:14                       ` Alexander Holler
2015-09-19 14:22                       ` Theodore Ts'o
2015-09-19 17:47                         ` Alexander Holler [this message]
2015-09-20  2:21                           ` Theodore Ts'o
2015-09-20 10:41                             ` Alexander Holler
2015-09-21 15:47                               ` Austin S Hemmelgarn
2015-09-21 17:20                                 ` Alexander Holler
2015-09-21 18:41                                 ` Alexander Holler
2015-09-23  8:59                               ` Alexander Holler
2015-09-28  6:54                     ` Thiago Farina
2015-09-28 14:20                       ` Greg KH
2015-09-16 20:02         ` Greg KH
2015-09-16 20:21           ` Eric Curtin
2015-09-16 22:38             ` Greg KH
2015-09-22 17:38 ` Linus Torvalds
2015-09-22 18:18   ` Eric Curtin
2015-09-25 22:06     ` Dmitry Torokhov
2015-09-26 13:28       ` Eric Curtin
2015-09-29 13:51         ` Austin S Hemmelgarn
2015-09-29 14:47           ` Eric Curtin
  -- strict thread matches above, loose matches on Subject: below --
2015-09-15 19:52 Eric Curtin
2015-09-15 21:57 ` Alexander Duyck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55FD9FAA.3070401@ahsoftware.de \
    --to=holler@ahsoftware.de \
    --cc=ahferroin7@gmail.com \
    --cc=ericcurtin17@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jwboyer@fedoraproject.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=shuah.kh@samsung.com \
    --cc=stevecalfee@gmail.com \
    --cc=tytso@mit.edu \
    --cc=valentina.manea.m@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox