[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080221132252.GC14614@mit.edu>
Date: Thu, 21 Feb 2008 08:22:52 -0500
From: Theodore Tso <tytso@....EDU>
To: Adrian Bunk <bunk@...nel.org>
Cc: Stefan Richter <stefanr@...6.in-berlin.de>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Russell King <rmk+lkml@....linux.org.uk>,
Andrew Morton <akpm@...ux-foundation.org>,
Trond Myklebust <trond.myklebust@....uio.no>,
Arjan van de Ven <arjan@...radead.org>,
Greg KH <greg@...ah.com>, LKML <linux-kernel@...r.kernel.org>,
linux-next@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: Announce: Linux-next (Or Andrew's dream :-))
On Wed, Feb 20, 2008 at 07:13:16PM +0200, Adrian Bunk wrote:
> > A third option would be if people add new functions (with no users) in
> > -rc2 or -rc3 timeframes as long as it is part of a fully reviewed
> > patch with users that will use those new features in various kernel
> > development trees.
> >...
>
> I don't like suggestions based on unrealistic assumptions like
> "a fully reviewed patch".
>
> E.g. userspace ABI's are much more stable and everyone is aware that
> they must be gotten right with the first try since they are then cast in
> stone - but we all remember the recent timerfd fiasco.
I'm talking about kernel interfaces, not userspace API's. And we can
change them if they are wrong, since they *are* kernel interfaces; but
if they correct, they ease the cross-tree merge pain.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists