linux-kernel - Re: CONFIG_OPTIMIZE

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]

Date:	Mon, 28 Apr 2008 13:42:14 +0300
From:	Adrian Bunk <bunk@...nel.org>
To:	Pavel Machek <pavel@....cz>
Cc:	David Miller <davem@...emloft.net>, mingo@...e.hu,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, viro@...IV.linux.org.uk
Subject: Re: CONFIG_OPTIMIZE_INLINING

On Sun, Apr 27, 2008 at 07:25:43PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > ... as i saw no reason why this feature, which i found rather useful, 
> > > should be delayed another year or so. I'd be more than happy to promote 
> > > this feature back to lib/Kconfig.debug, sparc64 interest would make that 
> > > a strong argument.
> > 
> > So you caved in to FUD in order to pad your commit and signoff count?
> > 
> > Because anyone who is paying attention can see clearly that you're
> > trying to push as much stuff as quickly as possible into Linus's tree
> > with your singoffs and authorship on it this merge window.
> > 
> > Gee, I wonder why...
> 
> What is going on here?
> 
> Yes, Ingo wants to merge a lots of stuff so that he does not have to
> maintain it for two more months. That's the result of 14-days merge
> window decission. ... 
> 
> No, I don't like that, either, but I don't think you can blame Ingo
> for the merge window.

Do you remember the IDE disaster during 2.5?
It was caused by a maintainer sending unreviewed patches directly
to Linus.

What gets merged during the merge window should have been reviewed weeks 
or months earlier, and have gotten tested for some weeks by people 
(that's what linux-next and -mm are for).

If someone has fresh stuff during a merge window the best solution in 
many cases is to keep it for the next merge window, and get it properly 
reviewed and tested in the meantime.

We have serious problems to cope with the regressions that get merged 
during a merge window, and the options are:
- very buggy stable kernels
- longer release cycles (which in turn result in even more stuff being
  merged during merge windows, making all problems even worse)
- get stuff reviewed and tested *before* it hits mainline

We are currently changing more than one million lines per release, 
and we somehow need to ensure that we don't ruin Linux' reputation
as a stable OS due to a lack of QA.

> 							Pavel

cu
Adrian

BTW:
This obviously doesn't strictly apply to e.g. new drivers or simple
patches (although we really need a better review for drivers before 
merging, since usually once they are in Linus' tree noone (except Al)
does serious cleanups on them).

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

--
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/