On Wed, 30 Apr 2008 21:36:57 +0200
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:
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?
--
