From: Greg KH <gregkh@suse.de>
To: david@lang.hm
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>,
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@elte.hu>
Subject: Re: removing existing working drivers via staging
Date: Thu, 15 Oct 2009 13:56:54 -0700 [thread overview]
Message-ID: <20091015205654.GA5127@suse.de> (raw)
In-Reply-To: <alpine.DEB.2.00.0910151244561.22169@asgard.lang.hm>
On Thu, Oct 15, 2009 at 12:49:40PM -0700, david@lang.hm wrote:
> On Thu, 15 Oct 2009, Stefan Richter wrote:
>
> > david@lang.hm wrote:
> >> a driver in staging will be able to build, but a driver that was removed
> >> after 6-9 months that a user discovered the removal of a year later when
> >> they upgraded to a new distro release (say a normal ubuntu release after
> >> staying on the old one for the 18 month support period) is likely to
> >> need significant work to catch up with kernel changes in the meanwhile.
> >
> > I don't think this new mechanism is meant to be, or can ever be, a way
> > to remove things that work and that users need.
>
> the problem I have is that the criteria that I have seen voiced for why
> something would move into staging does not require that it not work. it
> just requires that it need 'cleanup' of some sort.
>
> removing something that worked always runs a significant risk that someone
> out there 'needs' it (sometimes removing something that's broken, but
> works in some cases causes similar problems)
>
> > Hence the timeline of 3 releases per <20091015164726.GA10125@suse.de>
> > affects developers/ janitors much more than end users.
>
> it may be that I've jumped the gun here with my concerns, and should just
> wait until something actually gets moved to staging to see what the actual
> policies are going to be in practice, but the policies as written seem to
> be very loose.
Loose is good, it gives us much room in which to work with, taking each
case as it comes.
Let's all see how it goes before declaring this whole thing is broken.
There's no reason we can't constantly reevaluate it as time goes on, as
nothing we ever do here is set in stone :)
thanks,
greg "the only constant is change" k-h
next prev parent reply other threads:[~2009-10-15 21:04 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-15 5:27 removing existing working drivers via staging david
2009-10-15 16:33 ` Stefan Richter
2009-10-15 16:39 ` david
2009-10-15 16:47 ` Greg KH
2009-10-15 17:42 ` Bartlomiej Zolnierkiewicz
2009-10-15 17:49 ` Greg KH
2009-10-15 18:20 ` Bartlomiej Zolnierkiewicz
2009-10-15 18:46 ` Greg KH
2009-10-15 18:58 ` Bartlomiej Zolnierkiewicz
2009-10-15 19:02 ` david
2009-10-15 19:16 ` Ingo Molnar
2009-10-15 19:38 ` david
2009-10-15 19:47 ` Stefan Richter
2009-10-15 19:57 ` david
2009-10-27 4:23 ` david
2009-10-27 5:22 ` David Miller
2009-10-27 5:50 ` david
2009-10-27 14:06 ` Greg KH
2009-10-27 10:45 ` Alan Cox
2009-10-16 7:40 ` Ingo Molnar
2009-10-16 7:58 ` Justin P. Mattock
2009-10-15 19:40 ` Stefan Richter
2009-10-15 19:49 ` david
2009-10-15 20:56 ` Greg KH [this message]
2009-10-16 7:25 ` Ingo Molnar
2009-10-15 18:44 ` Alan Cox
2009-10-15 19:24 ` David Miller
2009-10-17 17:27 ` Pavel Machek
2009-10-19 7:32 ` Ingo Molnar
2009-10-19 7:40 ` Greg KH
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=20091015205654.GA5127@suse.de \
--to=gregkh@suse.de \
--cc=bzolnier@gmail.com \
--cc=david@lang.hm \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=stefanr@s5r6.in-berlin.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox