linux-kernel - Re: Moving drivers into staging (was Re: [GIT PULL] SCSI fixes for 2.6.32-rc3)

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20091014063308.GE784@elte.hu>
Date:	Wed, 14 Oct 2009 08:33:08 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Joe Perches <joe@...ches.com>
Cc:	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,
	linux-wireless@...r.kernel.org
Subject: Re: Moving drivers into staging (was Re: [GIT PULL] SCSI fixes for
	2.6.32-rc3)

* Joe Perches <joe@...ches.com> wrote:

> On Tue, 2009-10-13 at 21:45 -0700, Greg KH wrote:
> > How about when it was scheduled to be removed, we put it in staging and
> > I'll add it to my announcements about the staging tree every release?
> > Unless you can think of a better way?
> 
> staging/to_be_removed_unless_fixed_by/v.x.y ?

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.

A third version would be a more neutral name:

  drivers/staging/incoming/
  drivers/staging/outgoing/

I think it has many advantages, but (of course!) it all depends on 
whether Greg wants to have any separation like this.

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