linux-kernel - Re: overdue items in feature-removal-schedule

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: <Pine.LNX.4.64.0712031812170.11746@fbirervta.pbzchgretzou.qr>
Date:	Mon, 3 Dec 2007 18:19:44 +0100 (CET)
From:	Jan Engelhardt <jengelh@...putergmbh.de>
To:	Erez Zadok <ezk@...sunysb.edu>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Christoph Hellwig <hch@....de>
Subject: Re: overdue items in feature-removal-schedule


On Dec 3 2007 11:58, Erez Zadok wrote:
>
>What:	remove EXPORT_SYMBOL(kernel_thread)
>When:	August 2006
>
>One feature (removal of sys_sysctl) is listed for September 2010: are we
>really able to predict the future with this much accuracy?
>
>When, if at all, will those future/overdue features be removed for real?
>Have any of them been removed already?  It's very important to developers to
>have more accurate removal schedule for planning purposes.
>
>I think setting dates on feature removal isn't compatible with the current
>model of kernel code development, b/c despite our best efforts, it's hard to
>predict the precise release of the next 2.6.(x+1) kernel.

The release dates of Linux kernels are much more deterministic than
the removal dates in feature-removal-schedule.txt are accurate.

The reason I see for this is that many list readers do not object
patches that extend frs.txt, but there is always 'a lot' of
resistance when actually attempting to remove code. raw.ko is
probably the best example.

This kinda defeats the purpose of frs.txt. If subsys maintainers do
not croak when they see patches that add to frs.txt (assuming the
maintainers see the patches, to be fair), I take it they agree to
removing the feature soon. If not, the textfile should probably be
renamed to features-we-would-like-to-get-rid-of-sooner-or-later.txt.
--
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/