On Wed, 17 Jan 2007 11:51:27 EST, "Robert P. J. Day" said: > > in any event, what about introducing a new config variable, > OBSOLETE, under "Code maturity level options"? this would seem to be > a quick and dirty way to prune anything that is *supposed* to be > obsolete from the build, to make sure you're not picking up dead code > by accident. > > i think it would be useful to be able to make that kind of > distinction since, as the devfs writer pointed out above, the point of > labelling something "obsolete" is not to *discourage* someone from > using a feature, it's to imply that they *shouldn't* be using that > feature. period. which suggests there should be an easy, one-step > way to enforce that absolutely in a build. How much of the 'OBSOLETE' code should just be labelled 'BROKEN' instead?
Attachment:
pgpTvAZt8yPL2.pgp
Description: PGP signature
- Follow-Ups:
- Re: "obsolete" versus "deprecated", and a new config option?
- From: "Robert P. J. Day" <[email protected]>
- Re: "obsolete" versus "deprecated", and a new config option?
- References:
- "obsolete" versus "deprecated", and a new config option?
- From: "Robert P. J. Day" <[email protected]>
- "obsolete" versus "deprecated", and a new config option?
- Prev by Date: Re: [PATCH -mm 0/10][RFC] aio: make struct kiocb private
- Next by Date: Re: [PATCH] nfs: fix congestion control
- Previous by thread: Re: "obsolete" versus "deprecated", and a new config option?
- Next by thread: Re: "obsolete" versus "deprecated", and a new config option?
- Index(es):
 |