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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <alpine.DEB.2.00.0910151244561.22169@asgard.lang.hm>
Date:	Thu, 15 Oct 2009 12:49:40 -0700 (PDT)
From:	david@...g.hm
To:	Stefan Richter <stefanr@...6.in-berlin.de>
cc:	Greg KH <gregkh@...e.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, 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.

David Lang
--
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/