mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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


  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®