linux-kernel - Re: [git pull] IDE fixes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <200904230051.24622.bzolnier@gmail.com>
Date:	Thu, 23 Apr 2009 00:51:24 +0200
From:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
To:	Ray Lee <ray-lk@...rabbit.org>
Cc:	Joe Perches <joe@...ches.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [git pull] IDE fixes

On Thursday 23 April 2009 00:02:38 Ray Lee wrote:
> On Wed, Apr 22, 2009 at 2:41 PM, Bartlomiej Zolnierkiewicz
> <bzolnier@...il.com> wrote:
> > On Wednesday 22 April 2009 21:55:03 Joe Perches wrote:
> >> On Wed, 2009-04-22 at 21:43 +0200, Bartlomiej Zolnierkiewicz wrote:
> >> > IMO we should just remove extra commas and add some whitespaces.
> >>
> >> Your choice.
> >> Ignore, reject, accept, improve, fine by me.
> >>
> >> > I have also more general (process oriented) comment:
> >> >
> >> > All patches have been posted to linux-kernel or linux-ide for review before
> >> > and it is _much_ more efficient to raise issues (including CodingStyle ones)
> >> > during "review phase" instead of during "push to Linus" phase.
> >>
> >> Maybe for you, but I'm an intermittent
> >> and random reader.
> >
> > For everybody involved in the process -- this includes you.
> >
> > I'm not the original author of many patches so I simply cannot be
> > correcting every single issue because:
> >
> > a) it is physically impossible
> >
> > b) it doesn't really educate people
> 
> His point is that you can queue a follow-up patch to remove the
> ugliness. Just because it didn't get caught until the push stage
> doesn't mean the code needs to stay set in stone for the rest of
> eternity.

I get his point and of course patches are welcomed.

However my point is that it is still suboptimal way to address
the issue in the long-term and from my perspective the long-term
is what really matters.

Thanks,
Bart
--
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/