From: Adrian Bunk <bunk@kernel.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: David Miller <davem@davemloft.net>,
mingo@elte.hu, linux-kernel@vger.kernel.org,
torvalds@linux-foundation.org, akpm@linux-foundation.org,
viro@ZenIV.linux.org.uk
Subject: Re: CONFIG_OPTIMIZE_INLINING
Date: Mon, 28 Apr 2008 13:42:14 +0300 [thread overview]
Message-ID: <20080428104214.GH16379@cs181133002.pp.htv.fi> (raw)
In-Reply-To: <20080427172542.GA5485@ucw.cz>
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
next prev parent reply other threads:[~2008-04-28 10:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-27 4:55 CONFIG_OPTIMIZE_INLINING David Miller
2008-04-27 5:59 ` CONFIG_OPTIMIZE_INLINING Ingo Molnar
2008-04-27 6:08 ` CONFIG_OPTIMIZE_INLINING David Miller
2008-04-27 8:20 ` CONFIG_OPTIMIZE_INLINING Ingo Molnar
2008-04-27 9:10 ` CONFIG_OPTIMIZE_INLINING SL Baur
2008-04-27 9:16 ` CONFIG_OPTIMIZE_INLINING Dave Airlie
2008-04-27 9:21 ` CONFIG_OPTIMIZE_INLINING David Miller
2008-04-27 12:13 ` CONFIG_OPTIMIZE_INLINING Ingo Molnar
2008-04-27 11:22 ` CONFIG_OPTIMIZE_INLINING Ingo Molnar
2008-04-27 17:25 ` CONFIG_OPTIMIZE_INLINING Pavel Machek
2008-04-28 10:42 ` Adrian Bunk [this message]
2008-04-27 6:26 ` CONFIG_OPTIMIZE_INLINING Christoph Hellwig
2008-04-27 10:56 ` CONFIG_OPTIMIZE_INLINING Sam Ravnborg
2008-04-27 6:02 ` CONFIG_OPTIMIZE_INLINING Sam Ravnborg
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=20080428104214.GH16379@cs181133002.pp.htv.fi \
--to=bunk@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=pavel@ucw.cz \
--cc=torvalds@linux-foundation.org \
--cc=viro@ZenIV.linux.org.uk \
/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
all inboxes | Powered by JetHome®