linux-kernel - Staging, place holder for better company/community development model

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 2 Mar 2009 23:14:56 -0800
From:	"Luis R. Rodriguez" <mcgrof@...il.com>
To:	Greg KH <greg@...ah.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Jouni Malinen <j@...fi>, Sujith <m.sujith@...il.com>,
	Sujith <Sujith.Manoharan@...eros.com>,
	Senthilkumar Balasubramanian 
	<Senthilkumar.Balasubramanian@...eros.com>,
	Johannes Berg <johannes@...solutions.net>,
	"John W. Linville" <linville@...driver.com>,
	Christoph Hellwig <hch@...radead.org>,
	Vasanthakumar Thiagarajan <vasanth@...eros.com>
Subject: Staging, place holder for better company/community development model

A lot of people really hate the staging tree. I don't but let me tell
you why and I'd like to see if you concur with these particular
concrete use cases and ideas on how to further use it.

The ath9k driver came to many as a big surprise -- and since it was a
surprise we had to do the work ourselves as a team at Atheros in
closed doors, without the community's involvement until we got
something standing up and not smelling as bad. Our own change in
direction to work on things upstream can be seen later as well by the
release of the 11n Otus driver and documentation provided to
interested developers to port it to mac80211 (not to mention similar
type of work for ath5k) -- Johannes quickly then ported it and created
the ar9170 11n USB driver which is its replacement for otus and
targeted for wireless-testing. Otus is currently part of the staging
tree. While ar9170 has no 802.11n support users wishing to test 11n
USB with an open driver can use the "vendor" driver. The idea is to
minimize as time goes by the "port" effort and get things out to the
community faster.

With future devices we may want to create a better path for
integration into upstream drivers. But I also want users to get
support for the devices as soon as those devices hit shelves in the
market, maybe even before. So I would like to think of staging not
only as a place for people to put drivers which a company has no
resources to do the right job but also perhaps to _do_ the actual port
work _with_ the community together. By doing so we get devices
supported with whatever ugly piece of code makes the device run (as
long as its open, upstreamble, etc) but we also can engage with the
community on the actual engineering and future of the actual driver we
do want to support in Linux.

As time goes by hopefully staging will not be necessary as companies
(like ours) will have an immediate well defined structure for their
drivers to easily add support for further devices.

If we should take this approach -- should we send patches for wireless
staging to John, or Greg? It would still be "crap" so I don't expect
John to accept to help maintain crap but what if its crap with a clear
defined path to un-crap land?

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