linux-kernel - Re: Slow DOWN, please!!!

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:	Wed, 30 Apr 2008 13:00:58 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	davem@...emloft.net, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, jirislaby@...il.com
Subject: Re: Slow DOWN, please!!!

On Wed, 30 Apr 2008 21:36:57 +0200
"Rafael J. Wysocki" <rjw@...k.pl> wrote:

> On Wednesday, 30 of April 2008, David Miller wrote:
> > 
> > This is starting to get beyond frustrating for me.
> > 
> > Yesterday, I spent the whole day bisecting boot failures
> > on my system due to the totally untested linux/bitops.h
> > optimization, which I fully analyzed and debugged.
> > 
> > Today, I had hoped that I could get some work done of my
> > own, but that's not the case.
> > 
> > Yet another bootup regression got added within the last 24
> > hours.
> > 
> > I don't mind fixing the regression or two during the merge
> > window but THIS IS ABSOLUTELY, FUCKING, REDICULIOUS!
> > 
> > The tree breaks every day, and it's becomming an extremely
> > non-fun environment to work in.
> > 
> > We need to slow down the merging, we need to review things
> > more, we need people to test their fucking changes!
> 
> Well, I must say I second that.

ooh, fun thread.

One of the main reasons for -mm (probably _the_ main reason) is to weed out
other-developer-impacting regressions before they hit mainline and, umm,
affect developers.

But there are implementation problems:

a) developers aren't testing -mm enough

b) -mm releases have become too slow, and (hence) too unstable

c) people are slamming changes into mainline which have never been seen
   in -mm.  Lots of changes.

So here's how we're going to fix David's problem:

- Everyone gets their stuff into linux-next.

- Lots of people _test_ linux-next.  Just once a week.

Those two steps will improve the merge-window chaos a lot.  Things will get
better.

The remaining open problem is what do we do about the shiny new code which
is getting slammed into the merge window?

Well, it's very easy to tell whether code which appears in the merge window
was present in linux-next.

Our first way of preventing people from shoving inadequately-cooked code
into the merge window is suasion (aka flaming their titties off).  If that
proves insufficient and if we still have a sufficiently large problem that
we need to do something about it then sure, let's reevaluate.

But one thing at a time.  For the 2.6.27 release let us concentrte on two
things

- get your stuff into linux-next

- test linux-next.

If merge-window stability is still a problem after that then let's revisit?
--
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/