Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)

[Larry McVoy <lm@bitmover.com>]

Make it async.  So anyone can review stuff and record their feelings in a
centralized place.  We have a spare machine set up, kernel.bkbits.net, 
that could be used as a dumping grounds for patches and reviews if
master.kernel.org is too locked down.

If you force the review process into a "push" model where patches are 
sent to someone, then you are stuck waiting for them to review it and
it may or may not happen.  Do the reviews in a centralized place where
everyone can see them and add their own comments.

On Wed, Dec 18, 2002 at 02:08:02PM -0500, Alan Cox wrote:
> > 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/

-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm