Re: maturity and status and attributes, oh my!

[Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>]

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