[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4AD5DCA7.5060704@emulex.com>
Date: Wed, 14 Oct 2009 10:13:59 -0400
From: James Smart <James.Smart@...lex.Com>
To: Ingo Molnar <mingo@...e.hu>
CC: Joe Perches <joe@...ches.com>, Greg KH <gregkh@...e.de>,
"Luis R. Rodriguez" <mcgrof@...il.com>,
James Bottomley <James.Bottomley@...e.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Theodore Tso <tytso@....edu>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-scsi <linux-scsi@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Jing Huang <huangj@...cade.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>
Subject: Re: Moving drivers into staging (was Re: [GIT PULL] SCSI fixes for
2.6.32-rc3)
Ingo Molnar wrote:
> Yes, that's a real worry. Some time ago i suggested:
>
> drivers/staging/good/
> drivers/staging/bad/
> drivers/staging/ugly/
>
> good: drivers that are to go upstream in the next cycle
> bad: outgoing drivers being obsoleted or abandoned
> ugly: incoming messy drivers with active developers
>
> The messaging of this looks nice and the names are short and obvious.
>
> An added benefit is that this kind of separation makes it easy for
> people interested in drivers/staging to follow the 'status' of drivers.
> Once stuff goes into 'good' a different kind of review is needed than if
> a driver goes into 'ugly'.
>
> The main disadvantage would be the PR angle: putting new drivers into a
> path named 'ugly'. Not something you want to put into a quarterly status
> report, right? If we put drivers/staging/ugly/ drivers into
> drivers/staging/ itself, we'd solve that problem. I.e. we'd keep the
> current scheme, but we'd also add drivers/staging/good/ and
> drivers/staging/bad/ as two extra stages for incoming and outgoing
> drivers.
Change "ugly" to "wip" (work in progress). Should remove the negative
connotation and keeps things short. Does miss the spaghetti western theme
though :)
-- james s
--
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