From: Ingo Molnar <mingo@elte.hu>
To: Joe Perches <joe@perches.com>
Cc: Greg KH <gregkh@suse.de>, "Luis R. Rodriguez" <mcgrof@gmail.com>,
James Bottomley <James.Bottomley@suse.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
Theodore Tso <tytso@mit.edu>,
Andrew Morton <akpm@linux-foundation.org>,
linux-scsi <linux-scsi@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Jing Huang <huangj@brocade.com>,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org
Subject: Re: Moving drivers into staging (was Re: [GIT PULL] SCSI fixes for 2.6.32-rc3)
Date: Wed, 14 Oct 2009 08:33:08 +0200 [thread overview]
Message-ID: <20091014063308.GE784@elte.hu> (raw)
In-Reply-To: <1255497575.1851.16.camel@Joe-Laptop.home>
* Joe Perches <joe@perches.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
next prev parent reply other threads:[~2009-10-14 6:33 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-06 15:46 [GIT PULL] SCSI fixes for 2.6.32-rc3 James Bottomley
2009-10-06 15:58 ` Linus Torvalds
2009-10-06 20:54 ` James Bottomley
2009-10-06 20:56 ` Randy Dunlap
2009-10-08 14:33 ` James Bottomley
2009-10-08 14:39 ` Linus Torvalds
2009-10-08 14:54 ` Linus Torvalds
2009-10-08 19:48 ` James Bottomley
2009-10-08 19:55 ` Linus Torvalds
2009-10-08 20:00 ` Linus Torvalds
2009-10-08 21:07 ` Theodore Tso
2009-10-08 21:13 ` Linus Torvalds
2009-10-09 9:15 ` Ingo Molnar
2009-10-09 13:10 ` Daniel Walker
2009-10-09 14:08 ` James Bottomley
2009-10-09 19:25 ` Greg KH
2009-10-12 13:06 ` Ingo Molnar
2009-10-12 14:19 ` James Bottomley
2009-10-12 14:54 ` Ingo Molnar
2009-10-12 15:09 ` Moving drivers into staging (was Re: [GIT PULL] SCSI fixes for 2.6.32-rc3) Greg KH
2009-10-12 15:42 ` Ingo Molnar
2009-10-12 23:24 ` Greg KH
2009-10-12 23:24 ` Greg KH
2009-10-13 18:08 ` Luis R. Rodriguez
2009-10-13 18:08 ` Luis R. Rodriguez
2009-10-14 4:45 ` Greg KH
2009-10-14 5:19 ` Joe Perches
2009-10-14 5:19 ` Joe Perches
2009-10-14 6:33 ` Ingo Molnar [this message]
2009-10-14 14:13 ` James Smart
2009-10-14 17:52 ` Stefan Richter
2009-10-14 18:36 ` Ingo Molnar
2009-10-14 19:00 ` Stefan Richter
2009-10-15 6:03 ` Ingo Molnar
2009-10-14 19:11 ` Greg KH
2009-10-12 15:43 ` James Bottomley
2009-10-12 15:43 ` James Bottomley
2009-10-12 23:26 ` Greg KH
2009-10-12 15:25 ` [GIT PULL] SCSI fixes for 2.6.32-rc3 James Bottomley
2009-10-12 17:24 ` Linus Torvalds
2009-10-13 14:29 ` James Bottomley
2009-10-12 14:25 ` Greg KH
2009-10-08 20:04 ` James Bottomley
2009-10-08 20:25 ` Linus Torvalds
2009-10-10 14:37 ` James Bottomley
2009-10-08 14:56 ` James Bottomley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091014063308.GE784@elte.hu \
--to=mingo@elte.hu \
--cc=James.Bottomley@suse.de \
--cc=akpm@linux-foundation.org \
--cc=gregkh@suse.de \
--cc=huangj@brocade.com \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=mcgrof@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.