[Fwd: Stability fixes only, _please_]

[Fwd: Stability fixes only, _please_]

[Len Brown]

[-- Attachment #1: Type: text/plain, Size: 346 bytes --]

In the event you haven't see Linus's request to include bug-fixes only
in 2.6.0 from here on out.

I think that:
1. if bugzilla entries are associated with each patch,
   that will help make the case.
2. I should probably to create a linux-acpi-test-2.6.1 tree now
   to hold stuff that will need to wait for that release to open.

thanks,
-Len


[-- Attachment #2: Forwarded message - Stability fixes only, _please_ --]
[-- Type: message/rfc822, Size: 5622 bytes --]

From: Linus Torvalds <torvalds-3NddpPZAyC0@public.gmane.org>
To: David Miller <davem-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, Randy Dunlap <rddunlap@osdl.org>, Andrea Arcangeli <andrea@suse.de>, Arnaldo Carvalho de Melo <acme@conectiva.com.br>, Dave Jones <davej@redhat.com>, Dave Kleikamp <shaggy@austin.ibm.com>, David Mosberger <davidm@napali.hpl.hp.com>, Greg KH <greg@kroah.com>, Ingo Molnar <mingo@redhat.com>, James Bottomley <James.Bottomley@SteelEye.com>, Jaroslav Kysela <perex@suse.cz>, Jeff Garzik <jgarzik@pobox.com>, Len Brown <len.brown@intel.com>, Nick Piggin <piggin@cyberone.com.au>, Patrick Mochel <mochel@osdl.org>, Paul Mackerras <paulus@samba.org>, Russell King <rmk@arm.linux.org.uk>, Rusty Russell <rusty@rustcorp.com.au>, Sam Ravnborg <sam@ravnborg.org>, Steve Lord <lord@sgi.com>, Stephen Hemminger <shemminger@osdl.org>, Trond Myklebust <trond.myklebust@fys.uio.no>, Vojtech Pavlik <vojtech@suse.cz>, Andrew Morton <akpm@osdl.org>
Cc: Architectures Group <linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Stability fixes only, _please_
Date: Wed, 8 Oct 2003 13:13:40 -0700 (PDT)
Message-ID: <Pine.LNX.4.44.0310081250390.2031-100000-Xqd2YWsQM6mXDw4h08c5KA@public.gmane.org>


[ The recipient list is a list of people who I have merged with through BK
  fairly recently or are otherwise active (or are just a result of random
  grepping on my mailbox and/or the changelog). The BK side is
  particularly important, since unlike patches, with BK I can't just
  select the parts I want. ]

I just released 2.6.0-test7, and I'm _really_ hoping to calm down
development by the end of October. The test-releases have been about two
weeks apart, and they've been about half a megabyte of patches PER WEEK.  
Thst just isn't conductive to stabilization, because even if most of the
patches end up being fairly simple, it means that there are a LOT of
simple patches, and inevitably some of them have unintentional side 
effects (*).

In the 2.6.0-test7 release notes for the kernel mailing list, I said:

   The more interesting thing is that I and Andrew are trying to calm down 
   development, and I do _not_ want to see patches that don't fix a real and 
   clear bug. In other words, the "cleanup and janitorial" stuff is on hold, 
   and -test8 and then -test9 should be for _stability_ fixes only.

   In other words, this should calm things down so that by the end of October
   we can look at the state of 2.6.0 without having a lot of noise from "not
   strictly necessary" stuff.

and I _really_ need your help for this to work. In particular, it means
that you shouldn't point me to BK trees that may have a real bug fix, but
also have other noncritical stuff in them. 

And you should _not_ spend any time at all doing cleanups. Zero. If you
work for a Linux company, and your manager asks you to do cleanups, please
put some poison in his morning cereal. Or something (if you like your
manager - hah - just tell him why you shouldn't do cleanups).

And if you see a bug, and there is an ugly but _immediate_ fix for it, do
the ugly and immediate thing instead of trying to clean it up. Add a
"FIXME!" comment if that makes your conscience feel better, but don't
bother trying to do the clean thing that touches something else too.

Please.

Spread the word to "your guys" too, ok?

		Linus

(*) Euphemism of the day. They are buggy, or even if "perfect" they may
trigger a bug somewhere else. And even if they are perfect works of art, 
they distract us from what should matter now: the pure stability work.