linux-kernel - Re: removing existing working drivers via staging

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20091015205654.GA5127@suse.de>
Date:	Thu, 15 Oct 2009 13:56:54 -0700
From:	Greg KH <gregkh@...e.de>
To:	david@...g.hm
Cc:	Stefan Richter <stefanr@...6.in-berlin.de>,
	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: removing existing working drivers via staging

On Thu, Oct 15, 2009 at 12:49:40PM -0700, david@...g.hm wrote:
> On Thu, 15 Oct 2009, Stefan Richter wrote:
> 
> > david@...g.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@...e.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
--
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/