Re: "obsolete" versus "deprecated", and a new config option?
Robert P. J. Day wrote: that's entirely a judgment call on the part of the code's maintainer. if something is both obsolete and broken, then make it depend on *both* OBSOLETE and BROKEN if you want. no big deal. Yup. OBSOLETE = might be broken, no one is planning to maintain it. BROKEN = known to be broken. They're by and large orthogonal. -hpa - 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/
Re: obsolete versus deprecated, and a new config option?
Robert P. J. Day wrote: that's entirely a judgment call on the part of the code's maintainer. if something is both obsolete and broken, then make it depend on *both* OBSOLETE and BROKEN if you want. no big deal. Yup. OBSOLETE = might be broken, no one is planning to maintain it. BROKEN = known to be broken. They're by and large orthogonal. -hpa - 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/
Re: "obsolete" versus "deprecated", and a new config option?
On Wed, 17 Jan 2007, [EMAIL PROTECTED] wrote: > On Wed, 17 Jan 2007 17:04:20 EST, "Robert P. J. Day" said: > > > > How much of the 'OBSOLETE' code should just be labelled 'BROKEN' > > > instead? > > > > the stuff that's actually "broken." :-) > > Right - the question is how much code qualifies as either/both, and > which we should use when we encounter the random driver that's both > obsolete *and* broken... that's entirely a judgment call on the part of the code's maintainer. if something is both obsolete and broken, then make it depend on *both* OBSOLETE and BROKEN if you want. no big deal. rday - 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/
Re: "obsolete" versus "deprecated", and a new config option?
On Wed, 17 Jan 2007 17:04:20 EST, "Robert P. J. Day" said: > > How much of the 'OBSOLETE' code should just be labelled 'BROKEN' > > instead? > > the stuff that's actually "broken." :-) Right - the question is how much code qualifies as either/both, and which we should use when we encounter the random driver that's both obsolete *and* broken... pgpa0IdwHrAU9.pgp Description: PGP signature
Re: "obsolete" versus "deprecated", and a new config option?
On Wed, 17 Jan 2007, [EMAIL PROTECTED] wrote: > 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? the stuff that's actually "broken." :-) OBSOLETE is not (or at least *should not* be) equivalent to BROKEN. "OBSOLETE" should denote code that, while it is no longer supported and has a viable replacement, may very well still work. and it may or may not be slated for removal some day. there may very well be reasons to keep "obsolete" code in the kernel, for occasional backward compatibility, but marking it as "obsolete" is a powerful indicator that people should *really* try not to use it. "BROKEN" code, OTOH, really should mean exactly that -- code that is *known* to be broken. that would include old code that has suffered bit rot, but it might also include *new* code that, while it's now part of the kernel, someone discovers a major flaw in it and no one's got around to fixing it yet. so even bleeding-edge code can technically be "broken" until someone gets around to debugging it. thoughts? rday - 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/
Re: "obsolete" versus "deprecated", and a new config option?
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? pgpYtyUQ0sHVV.pgp Description: PGP signature
Re: "obsolete" versus "deprecated", and a new config option?
On Wed, 17 Jan 2007, Bill Davidsen wrote: > Robert P. J. Day wrote: > > a couple random thoughts on the notion of obsolescence and > > deprecation. > > [...horrible example deleted...] > > > so is that ioctl obsolete or deprecated? those aren't the same > > things, a good distinction being drawn here by someone discussing > > devfs: > > > > http://kerneltrap.org/node/1893 > > > > "Devfs is deprecated. This means it's still available but you > > should consider moving to other options when available. Obsolete > > means it shouldn't be used. Some 2.6 docs have confused these two > > terms WRT devfs." > > > > yes, and that confusion continues to this day, when a single > > feature is described as both deprecated and obsolete. not good. > > (also, i'm guessing that anything that's "obsolete" might deserve > > a default of "n" rather than "y", but that's just me. :-) > > Agree on that. I would hope "obsolete" means there's a newer way > which should provide the functionality (** help should say where > that is **) while depreciated should mean "we decided this was a bad > solution" or something like that. in simpler terms, "deprecated" (note correct spelling :-) should mean "it's still available and you can use it but you should seriously think of moving up soon 'cuz this is going to disappear some day," while "obsolete" should mean, "it's dead, jim." > > 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. > > If you're doing that, why not four variables, for incomplete, > experimental, obsolete and depreciated? Unfortunately doing any more > detailed nomenclature would be a LOT of work! i wouldn't go that far. using deprecated code is still technically fine, but using obsolete code should be something that raises a red flag of some kind. i would just somehow mark the OBSOLETE stuff. in fact, some kernel config options already do something like this, such as in drivers/mtd/chips/Kconfig: config MTD_OBSOLETE_CHIPS depends on MTD bool "Older (theoretically obsoleted now) drivers for non-CFI chips" help ... yadda yadda yadda ... config MTD_AMDSTD tristate "AMD compatible flash chip support (non-CFI)" depends on MTD && MTD_OBSOLETE_CHIPS && BROKEN ... and there's plenty of places in the Kconfig files that label features as obsolete. i just want the ability to switch all that stuff off with one mouse click and see what happens. rday - 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/
Re: "obsolete" versus "deprecated", and a new config option?
Robert P. J. Day wrote: a couple random thoughts on the notion of obsolescence and deprecation. [...horrible example deleted...] so is that ioctl obsolete or deprecated? those aren't the same things, a good distinction being drawn here by someone discussing devfs: http://kerneltrap.org/node/1893 "Devfs is deprecated. This means it's still available but you should consider moving to other options when available. Obsolete means it shouldn't be used. Some 2.6 docs have confused these two terms WRT devfs." yes, and that confusion continues to this day, when a single feature is described as both deprecated and obsolete. not good. (also, i'm guessing that anything that's "obsolete" might deserve a default of "n" rather than "y", but that's just me. :-) Agree on that. I would hope "obsolete" means there's a newer way which should provide the functionality (** help should say where that is **) while depreciated should mean "we decided this was a bad solution" or something like that. 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. If you're doing that, why not four variables, for incomplete, experimental, obsolete and depreciated? Unfortunately doing any more detailed nomenclature would be a LOT of work! 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. thoughts? I think it's a good idea, but doing it right may be more work than the benefit justifies. -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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/
Re: obsolete versus deprecated, and a new config option?
Robert P. J. Day wrote: a couple random thoughts on the notion of obsolescence and deprecation. [...horrible example deleted...] so is that ioctl obsolete or deprecated? those aren't the same things, a good distinction being drawn here by someone discussing devfs: http://kerneltrap.org/node/1893 Devfs is deprecated. This means it's still available but you should consider moving to other options when available. Obsolete means it shouldn't be used. Some 2.6 docs have confused these two terms WRT devfs. yes, and that confusion continues to this day, when a single feature is described as both deprecated and obsolete. not good. (also, i'm guessing that anything that's obsolete might deserve a default of n rather than y, but that's just me. :-) Agree on that. I would hope obsolete means there's a newer way which should provide the functionality (** help should say where that is **) while depreciated should mean we decided this was a bad solution or something like that. 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. If you're doing that, why not four variables, for incomplete, experimental, obsolete and depreciated? Unfortunately doing any more detailed nomenclature would be a LOT of work! 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. thoughts? I think it's a good idea, but doing it right may be more work than the benefit justifies. -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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/
Re: obsolete versus deprecated, and a new config option?
On Wed, 17 Jan 2007, Bill Davidsen wrote: Robert P. J. Day wrote: a couple random thoughts on the notion of obsolescence and deprecation. [...horrible example deleted...] so is that ioctl obsolete or deprecated? those aren't the same things, a good distinction being drawn here by someone discussing devfs: http://kerneltrap.org/node/1893 Devfs is deprecated. This means it's still available but you should consider moving to other options when available. Obsolete means it shouldn't be used. Some 2.6 docs have confused these two terms WRT devfs. yes, and that confusion continues to this day, when a single feature is described as both deprecated and obsolete. not good. (also, i'm guessing that anything that's obsolete might deserve a default of n rather than y, but that's just me. :-) Agree on that. I would hope obsolete means there's a newer way which should provide the functionality (** help should say where that is **) while depreciated should mean we decided this was a bad solution or something like that. in simpler terms, deprecated (note correct spelling :-) should mean it's still available and you can use it but you should seriously think of moving up soon 'cuz this is going to disappear some day, while obsolete should mean, it's dead, jim. 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. If you're doing that, why not four variables, for incomplete, experimental, obsolete and depreciated? Unfortunately doing any more detailed nomenclature would be a LOT of work! i wouldn't go that far. using deprecated code is still technically fine, but using obsolete code should be something that raises a red flag of some kind. i would just somehow mark the OBSOLETE stuff. in fact, some kernel config options already do something like this, such as in drivers/mtd/chips/Kconfig: config MTD_OBSOLETE_CHIPS depends on MTD bool Older (theoretically obsoleted now) drivers for non-CFI chips help ... yadda yadda yadda ... config MTD_AMDSTD tristate AMD compatible flash chip support (non-CFI) depends on MTD MTD_OBSOLETE_CHIPS BROKEN ... and there's plenty of places in the Kconfig files that label features as obsolete. i just want the ability to switch all that stuff off with one mouse click and see what happens. rday - 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/
Re: obsolete versus deprecated, and a new config option?
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? pgpYtyUQ0sHVV.pgp Description: PGP signature
Re: obsolete versus deprecated, and a new config option?
On Wed, 17 Jan 2007, [EMAIL PROTECTED] wrote: 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? the stuff that's actually broken. :-) OBSOLETE is not (or at least *should not* be) equivalent to BROKEN. OBSOLETE should denote code that, while it is no longer supported and has a viable replacement, may very well still work. and it may or may not be slated for removal some day. there may very well be reasons to keep obsolete code in the kernel, for occasional backward compatibility, but marking it as obsolete is a powerful indicator that people should *really* try not to use it. BROKEN code, OTOH, really should mean exactly that -- code that is *known* to be broken. that would include old code that has suffered bit rot, but it might also include *new* code that, while it's now part of the kernel, someone discovers a major flaw in it and no one's got around to fixing it yet. so even bleeding-edge code can technically be broken until someone gets around to debugging it. thoughts? rday - 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/
Re: obsolete versus deprecated, and a new config option?
On Wed, 17 Jan 2007 17:04:20 EST, Robert P. J. Day said: How much of the 'OBSOLETE' code should just be labelled 'BROKEN' instead? the stuff that's actually broken. :-) Right - the question is how much code qualifies as either/both, and which we should use when we encounter the random driver that's both obsolete *and* broken... pgpa0IdwHrAU9.pgp Description: PGP signature
Re: obsolete versus deprecated, and a new config option?
On Wed, 17 Jan 2007, [EMAIL PROTECTED] wrote: On Wed, 17 Jan 2007 17:04:20 EST, Robert P. J. Day said: How much of the 'OBSOLETE' code should just be labelled 'BROKEN' instead? the stuff that's actually broken. :-) Right - the question is how much code qualifies as either/both, and which we should use when we encounter the random driver that's both obsolete *and* broken... that's entirely a judgment call on the part of the code's maintainer. if something is both obsolete and broken, then make it depend on *both* OBSOLETE and BROKEN if you want. no big deal. rday - 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/
