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 =
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 =
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
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
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
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
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
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:
a couple random thoughts on the notion of obsolescence and
deprecation.
first, there are places in the kernel (primarily Kconfig files) and
the documentation that unnecessarily conflate these two properties.
as a simple example, consider drivers/pcmcia/Kconfig:
a couple random thoughts on the notion of obsolescence and
deprecation.
first, there are places in the kernel (primarily Kconfig files) and
the documentation that unnecessarily conflate these two properties.
as a simple example, consider drivers/pcmcia/Kconfig:
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:
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
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
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
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
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
16 matches
Mail list logo
