From: Alan Cox <alan@redhat.com>
Message-Id: <200212181908.gBIJ82M03155@devserv.devel.redhat.com>
Subject: Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
To: torvalds@transmeta.com (Linus Torvalds)
Date: Wed, 18 Dec 2002 14:08:02 -0500 (EST)
Cc: davej@codemonkey.org.uk (Dave Jones),
       vonbrand@inf.utfsm.cl (Horst von Brand), linux-kernel@vger.kernel.org,
       alan@redhat.com (Alan Cox), akpm@digeo.com (Andrew Morton)
In-Reply-To: <Pine.LNX.4.44.0212180936550.2891-100000@home.transmeta.com> from "Linus Torvalds" at Dec 18, 2002 09:41:15 AM
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1132
Lines: 32

> And I think it could work for the kernel too, especially the stable
> releases and for the process of getting there. I just don't really know
> how to set it up well.

A start might be

1.	Ack large patches you don't want with "Not for 2.6" instead
	of ignoring them. I'm bored of seeing the 18th resend of 
	this and that wildly bogus patch. 

	Then people know the status

2.	Apply patches only after they have been approved by the maintainer
	of that code area.

	Where it is core code run it past Andrew, Al and other people
	with extremely good taste.

3.	Anything which changes core stuff and needs new tools, setup
	etc please just say NO to for now. Modules was a mistake (hindsight
	I grant is a great thing), but its done. We don't want any more


4.	Violate 1-3 when appropriate as always, but preferably not to
	often and after consulting the good taste department 8)

Alan
-
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/