![]() | ||||||||||
Messages in this thread |
On Wednesday, 30 of April 2008, Andrew Morton wrote: > On Wed, 30 Apr 2008 21:36:57 +0200 > "Rafael J. Wysocki" <rjw@sisk.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. Yeah. > 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. For this to happen, let's make the mainline change slower than once a day after the merge window. > Those two steps will improve the merge-window chaos a lot. Things will get > better. Not until we make a rule that nothing that didn't went through linux-next is mergeable unless it's an obvious bugfix that has no side effects. > 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. OK > 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? I'll see you in the analogous thread during the next merge window. ;-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | |||||||||
| Last update: 2008-04-30 22:23 [W:0.414 / U:0.290 seconds] ©2003-2008 Jasper Spaans | ||||||||||