linux-kernel - Re: maturity and status and attributes, oh my!

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: <200709011544.07732.bzolnier@gmail.com>
Date:	Sat, 1 Sep 2007 15:44:07 +0200
From:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	"Robert P. J. Day" <rpjday@...dspring.com>,
	Stefan Richter <stefanr@...6.in-berlin.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: maturity and status and attributes, oh my!

On Saturday 01 September 2007, you wrote:
> Robert P. J. Day wrote:
> > On Sat, 1 Sep 2007, Jeff Garzik wrote:
> > 
> >> Feature deprecation and removal is a very amorphous concept that
> >> does not fit well at all into Kconfig markers, unlike
> >> experimental/broken.

The current approach (text file) is:
* centralized
* requires manual testing of all future changes
* totally invisible to the end-users (higly frustrating for them when
  they learn about scheduled changes when things brake)

The proposed approach (Kconfig) is:
* distributed
* allows partial automatic testing of future changes
* could be make visible to the end-users by smart use of macros/inlines
  and adding kernel parameter (would make users informed and encourage
  them to help with the development)

> > and, as i've said before, i disagree.  while one might debate what
> 
> Feel free to disagree -- I am describing how things play out on a day to 
> day basis.  In essence you are disagreeing with reality.

Part of the problem is that many people (including developers) learn about
things being deprecated/obsoleted after they are actually removed.

Of course things are not black and white and common sense is required but
moving in the Kconfig direction is an improvement IMO and could speed up
the development in the long-term.

BTW There is nothing wrong with disagreeing with the reality and trying
to change it.  If everybody would conform to the reality there will be no
progress at all... ;)

Bart
-
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/