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] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 7 Jun 2009 21:00:10 +0200
From:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
To:	Pekka Enberg <penberg@...helsinki.fi>
Cc:	James Bottomley <James.Bottomley@...senpartnership.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	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 Sunday 07 June 2009 20:21:11 Pekka Enberg wrote:
> Hi Bartlomiej,
> 
> On Sun, Jun 7, 2009 at 8:55 PM, Bartlomiej Zolnierkiewicz
> <bzolnier@...il.com> wrote:
> > On Sunday 07 June 2009 18:54:08 Pekka Enberg wrote:
> >> Hi Bartlomiej,
> >>
> >> On Sun, Jun 7, 2009 at 6:44 PM, Bartlomiej Zolnierkiewicz
> >> <bzolnier@...il.com> wrote:
> >> > Honestly, this should be solved on technical basis by somebody posting
> >> > needed libata patches instead of attempts to slow down IDE fixes.
> >>
> >> Nobody is "slowing down" IDE fixes here. Linus explicitly said that
> >> -rc8 is the last release candidate and the next one is going to be
> >> -final. There's absolutely _no way_ this series is appropriate at the
> >> very end of a release cycle.
> >
> > My honest opinion is that it is as appropriate now as it will be 2.6.31.
> >
> > [ I'm still amazed by the amount of *completely* bogus reasons given for
> >  not merging it. ]
> 
> I don't consider this a bogus reason at all:
> 
>  10 files changed, 134 insertions(+), 43 deletions(-)

Since when do we validate code quality based solely on LOC changed? :)

I'm yet to see anybody posting a single code chunk in this whole discussion.

> Just search the LKML archives for the amount of crap other subsystem
> maintainers have gotten from Linus when they've tried to sneak
> something like that after -rc4 or so.

How many of those other patches:

* got tested by the maintainer
* re-audited twice by the maintainer
* reviewed by two other subsystem gurus

Moreover there was no sneaking here at all:

I admitted in the pull request that I'm unsure if this is appropriate
that late in the cycle.

I'm fine with delaying those changes but I'm not fine with attempts to do
it using completely "made up" technical arguments (no risky core changes,
no 2K sector devices affected, no relation to alt_size sysfs interface, no
misrepresenting of feature as a bug fix -- to mention just a few).
--
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/