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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
