at the risk of driving everyone here totally bonkers, i'm going to
take one last shot at explaining what i was thinking of when i first
proposed this whole "maturity level" thing. and, just so you know,
the major reason i'm so cranked up about this is that i'm feeling just
a little territorial -- i was the one who first started nagging people
to consider this idea, so i'm a little edgy when i see folks finally
giving it some serious thought but appearing to get ready to implement
it entirely incorrectly in a way that's going to ruin it irreparably
and make it utterly useless.
this isn't just about defining a single feature called "maturity".
it's about defining a general mechanism so that you can add entirely
new (what i call) "attributes" to kernel features. one attribute
could be "maturity", which could take one of a number of possible
values. another could be "status", with the same restrictions.
heck, you could define the attribute "colour", and decide that various
kernel features could be labelled as (at most) one of "red", "green"
and "chartreuse." that's what i mean by an "attribute", and
attributes would have two critical and non-negotiable properties:
1) they would be entirely orthogonal to one another, and
2) they can be assigned at most one of a pre-defined set of values
that's it. it's really that simple and simon's earlier patch i
think fits that almost perfectly. now, back to the disagreement.
it may be that some people had a different understanding of what was
meant by "maturity" than i did. what *i* meant by that attribute is
a feature's current position in the normal software life cycle, and
that would be one of:
experimental -> normal (stable) -> deprecated -> obsolete
it's a natural progression and, at any point, a feature cannot
possibly have more than one maturity value. it would be as absurd as
saying that someone was a teenager *and* was a twenty-something at the
same time. not possible. and restricting an attribute to a single
value makes definitions and processing *way* easier down the road.
(and note that a feature's maturity says *nothing* about its current
level of quality. that's next.)
another attribute can then be what i was calling "status" but could
also be called "quality". *that* is where you could categorize a
feature as one of FLAKY, BROKEN and so on. that's an entirely
independent categorization from maturity, which means you could have
features that were both experimental and flaky, or deprecated and
broken, or what have you. and those settings would be done with
separate Kconfig directives:
config WHATEVER
maturity DEPRECATED
status BROKEN
from a quick perusal, simon's patch looked pretty much dead-on
(except for that teeth-grinding maturity level of BROKEN :-). but
other than that, it looked good, although i'll have to go back later
and look more closely.
but i hope i've flogged this thoroughly to the point where people
can see what i'm driving at. once you see (as in simon's patch) how
to add the first attribute, it's trivial to simply duplicate that code
to add as many more as you want.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
Robert P. J. Day wrote:
> it may be that some people had a different understanding of what was
> meant by "maturity" than i did. what *i* meant by that attribute is
> a feature's current position in the normal software life cycle, and
> that would be one of:
>
> experimental -> normal (stable) -> deprecated -> obsolete
People who actually write and maintain code disagree with your
imaginative interpretation.
Jeff, who notes the snipping of CC from previous thread
Robert P. J. Day wrote:
...
> attributes would have two critical and non-negotiable properties:
>
> 1) they would be entirely orthogonal to one another, and
> 2) they can be assigned at most one of a pre-defined set of values
If they are fully orthogonal to another, then they are also
nonexclusive. You want them to be mutual exclusive, not orthogonal.
...
> experimental -> normal (stable) -> deprecated -> obsolete
>
> it's a natural progression and, at any point, a feature cannot
> possibly have more than one maturity value. it would be as absurd as
> saying that someone was a teenager *and* was a twenty-something at the
> same time.
Keep in mind though that 'experimental', in the context of Linux kernel
features, has nothing to do with the age of a feature.
--
Stefan Richter
-=====-=-=== =--= ----=
http://arcgraph.de/sr/
On Fri, Aug 31, 2007 at 05:38:34PM -0400, Robert P. J. Day wrote:
> it may be that some people had a different understanding of what was
> meant by "maturity" than i did. what *i* meant by that attribute is
> a feature's current position in the normal software life cycle, and
> that would be one of:
>
> experimental -> normal (stable) -> deprecated -> obsolete
Life isn't so black and white.
* We have stuff go into the tree that isn't experimental on a regular
basis, due to proving outside of Linus' tree, be that in -mm, or
a distro tree, or anywhere else.
* We've had code become undeprecated a few times.
* Likewise stuff has sometimes got so fucked up that it's become
experimental again (see the longhaul driver for a great example
of a catastrophe in motion).
> it's a natural progression and, at any point, a feature cannot
> possibly have more than one maturity value. it would be as absurd as
> saying that someone was a teenager *and* was a twenty-something at the
> same time. not possible.
Again, not so black and white.
It's feasible that something can be experimental on one architecture,
stable on another (typically x86), or even deprecated on x86, but still
supported on other architectures.
It's not just a per arch thing either, in some cases, we've had
differing levels of maturity based upon other hardware constraints,
or even varying versions of system software.
> another attribute can then be what i was calling "status" but could
> also be called "quality". *that* is where you could categorize a
> feature as one of FLAKY, BROKEN and so on. that's an entirely
> independent categorization from maturity, which means you could have
> features that were both experimental and flaky, or deprecated and
> broken, or what have you. and those settings would be done with
> separate Kconfig directives:
Kconfig is an awful mechanism for tracking whether something is stable or not.
Take for example the skge net driver. It's "perfect" on some systems,
and utterly busted on others. How would you express that in Kconfig ?
Dave
--
http://www.codemonkey.org.uk
"Robert P. J. Day" wrote:
>
> at the risk of driving everyone here totally bonkers, i'm going to
> take one last shot at explaining what i was thinking of when i first
> proposed this whole "maturity level" thing. and, just so you know,
> the major reason i'm so cranked up about this is that i'm feeling just
> a little territorial -- i was the one who first started nagging people
> to consider this idea, so i'm a little edgy when i see folks finally
> giving it some serious thought but appearing to get ready to implement
> it entirely incorrectly in a way that's going to ruin it irreparably
> and make it utterly useless.
>
> this isn't just about defining a single feature called "maturity".
> it's about defining a general mechanism so that you can add entirely
> new (what i call) "attributes" to kernel features. one attribute
> could be "maturity", which could take one of a number of possible
> values. another could be "status", with the same restrictions.
> heck, you could define the attribute "colour", and decide that various
> kernel features could be labelled as (at most) one of "red", "green"
> and "chartreuse." that's what i mean by an "attribute", and
> attributes would have two critical and non-negotiable properties:
<<< snip>>>>
>
> but i hope i've flogged this thoroughly to the point where people
> can see what i'm driving at. once you see (as in simon's patch) how
> to add the first attribute, it's trivial to simply duplicate that code
> to add as many more as you want.
>
> rday
>
> --
> ========================================================================
> Robert P. J. Day
> Linux Consulting, Training and Annoying Kernel Pedantry
> Waterloo, Ontario, CANADA
>
> http://crashcourse.ca
> ========================================================================
Robert Day,
If I can interpret what you are asking about and changing it abit.
Don't you think that Maturity can be defined ALSO, as the
number of known bugs and their priority / serverity against a
architecture dependent or independent item?
Would this suffice and wouldn't it be easier to maintain?
Mitchell Erblich
On Sat, 1 Sep 2007, Stefan Richter wrote:
> Robert P. J. Day wrote:
> ...
> > attributes would have two critical and non-negotiable properties:
> >
> > 1) they would be entirely orthogonal to one another, and
> > 2) they can be assigned at most one of a pre-defined set of values
>
> If they are fully orthogonal to another, then they are also
> nonexclusive. You want them to be mutual exclusive, not orthogonal.
*attributes* would be orthogonal to one another -- the values *within*
an attribute would be mutually exclusive. maybe i phrased that badly
the first time. so a feature could have both a maturity *and* a
status (just using my hypothetical attributes here), but no feature
can have an attribute with more than one value.
ergo, you can have a maturity of, say, deprecated, *and* a status of,
say, broken. is that what you meant? it's what i was getting at.
> > experimental -> normal (stable) -> deprecated -> obsolete
> >
> > it's a natural progression and, at any point, a feature cannot
> > possibly have more than one maturity value. it would be as absurd
> > as saying that someone was a teenager *and* was a twenty-something
> > at the same time.
>
> Keep in mind though that 'experimental', in the context of Linux
> kernel features, has nothing to do with the age of a feature.
your point is well taken. i'm just trying to draw a clear distinction
between what i see as the natural chronological progression of a
feature, and its actual level of functionality, which i'm firmly
convinced represent two *very* different pieces of information.
something which is marked as obsolete can still be known to be
functioning perfectly well, while something which is still bleeding
edge might be well known to be broken as well.
with regard to "experimental", what attribute would you imagine it
would be a possible value for, and what other possible values might
that attribute have as opposed to experimental?
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
On Fri, 31 Aug 2007, Mitchell Erblich wrote:
> "Robert P. J. Day" wrote:
> >
> > at the risk of driving everyone here totally bonkers, i'm going to
> > take one last shot at explaining what i was thinking of when i first
> > proposed this whole "maturity level" thing. and, just so you know,
> > the major reason i'm so cranked up about this is that i'm feeling just
> > a little territorial -- i was the one who first started nagging people
> > to consider this idea, so i'm a little edgy when i see folks finally
> > giving it some serious thought but appearing to get ready to implement
> > it entirely incorrectly in a way that's going to ruin it irreparably
> > and make it utterly useless.
> >
> > this isn't just about defining a single feature called "maturity".
> > it's about defining a general mechanism so that you can add entirely
> > new (what i call) "attributes" to kernel features. one attribute
> > could be "maturity", which could take one of a number of possible
> > values. another could be "status", with the same restrictions.
> > heck, you could define the attribute "colour", and decide that various
> > kernel features could be labelled as (at most) one of "red", "green"
> > and "chartreuse." that's what i mean by an "attribute", and
> > attributes would have two critical and non-negotiable properties:
> <<< snip>>>>
> >
> > but i hope i've flogged this thoroughly to the point where people
> > can see what i'm driving at. once you see (as in simon's patch) how
> > to add the first attribute, it's trivial to simply duplicate that code
> > to add as many more as you want.
> >
> > rday
> >
> > --
> > ========================================================================
> > Robert P. J. Day
> > Linux Consulting, Training and Annoying Kernel Pedantry
> > Waterloo, Ontario, CANADA
> >
> > http://crashcourse.ca
> > ========================================================================
> Robert Day,
>
> If I can interpret what you are asking about and changing it abit.
>
> Don't you think that Maturity can be defined ALSO, as the
> number of known bugs and their priority / serverity against a
> architecture dependent or independent item?
>
> Would this suffice and wouldn't it be easier to maintain?
>
> Mitchell Erblich
perhaps. all i'm begging for is that these attributes be defined
cleanly and clearly, and following those two conditions i suggested
earlier:
1) all attributes are orthogonal to one another, and
2) values within an attribute are mutually exclusive
if you violate either of those conditions, i think you're going to
find it very difficult to design sane Kconfig entries around them.
if you don't believe me, give it a try.
rday
p.s. rather than saying that maturity can be defined "also" in
another way, you should say that it can be defined "instead" in
another way. i don't want to think what it might mean to define
something like maturity in two different ways simultaneously, if
that's what you were suggesting. that just makes my brain hurt.
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
On Aug 31 2007 18:02, Jeff Garzik wrote:
> Robert P. J. Day wrote:
>> it may be that some people had a different understanding of what was
>> meant by "maturity" than i did. what *i* meant by that attribute is
>> a feature's current position in the normal software life cycle, and
>> that would be one of:
>>
>> experimental -> normal (stable) -> deprecated -> obsolete
>
> People who actually write and maintain code disagree with your imaginative
> interpretation.
Might I point to the "designers and builders" thread...
http://lkml.org/lkml/2007/8/30/279 :)
Jan
--
On Aug 31 2007 21:33, Robert P. J. Day wrote:
>
>perhaps. all i'm begging for is that these attributes be defined
>cleanly and clearly, and following those two conditions i suggested
>earlier:
>
>1) all attributes are orthogonal to one another, and
This "orthogonal" argument is reserved for the cdrecord maintainer;
I cannot figure out what you mean by orthogonal. If A is orthogonal
to B and B is orthogonal to C, then A is parallel to C. If there are
more objects than dimensions, at least one pair of them is not
orthogonal. That is what orthogonal means to me ;-)
Jan
--
On Sat, 1 Sep 2007, Jan Engelhardt wrote:
>
> On Aug 31 2007 21:33, Robert P. J. Day wrote:
> >
> >perhaps. all i'm begging for is that these attributes be defined
> >cleanly and clearly, and following those two conditions i suggested
> >earlier:
> >
> >1) all attributes are orthogonal to one another, and
>
> This "orthogonal" argument is reserved for the cdrecord maintainer;
>
> I cannot figure out what you mean by orthogonal. If A is orthogonal
> to B and B is orthogonal to C, then A is parallel to C. If there are
> more objects than dimensions, at least one pair of them is not
> orthogonal. That is what orthogonal means to me ;-)
you're being too literal in a purely mathematical sense.
"orthogonality" has a much more general definition in the context of
computer science -- see here:
http://dict.die.net/orthogonal/
"The term is used loosely to mean mutually independent or well
separated. It is used to describe sets of primitives or capabilities
that, like linearly independent vectors in geometry, span the entire
"capability space" and are in some sense non-overlapping or mutually
independent."
and here:
"Computer science
"Orthogonality is a system design property facilitating feasibility
and compactness of complex designs. Orthogonality guarantees that
modifying the technical effect produced by a component of a system
neither creates nor propagates side effects to other components of the
system."
in the case of Kconfig "attributes", a set of orthogonal attributes
might be a variable's maturity, its colour and its flavour (i'm just
making those last two up, of course). and each of those clearly
orthogonal attributes is allowed to have at most one value, and that
value is entirely independent of what the value is of any of the
*other* attributes for that kernel feature.
i'm harping on this because it seems to me that lumping together
values such as experimental, deprecated, obsolete and broken in a
single attribute is creating a dangerously ill-defined attribute
that's trying to do two things at once -- identify both a variable's
"age", if you will, and its current code quality. and i'm simply
arguing that those are two different things and, if you do that, it
would prevent you from saying that some kernel feature is both
experimental *and* broken.
note: the above is assuming that an attribute is *defined* as being
allowed to have at most one possible value at a time, as in deprecated
*or* obsolete, and never deprecated *and* obsolete. if you go down
that second road, very bad things await you.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
On Fri, 31 Aug 2007, Dave Jones wrote:
> On Fri, Aug 31, 2007 at 05:38:34PM -0400, Robert P. J. Day wrote:
> > it's a natural progression and, at any point, a feature cannot
> > possibly have more than one maturity value. it would be as absurd
> > as saying that someone was a teenager *and* was a twenty-something
> > at the same time. not possible.
>
> Again, not so black and white. It's feasible that something can be
> experimental on one architecture, stable on another (typically x86),
> or even deprecated on x86, but still supported on other
> architectures. It's not just a per arch thing either, in some cases,
> we've had differing levels of maturity based upon other hardware
> constraints, or even varying versions of system software.
absolutely agreed. but in cases like that, it might just be easier to
not tag that feature *at all*. nothing in this proposal *forces*
someone to start tagging kernel features in any way. as you point
out, there may be cases where trying to tag a feature becomes so
hopelessly vague and special-cased, it's easier to just leave it
alone. but that still doesn't take away from the value of being able
to use this construct elsewhere where its use *is* clear-cut and
unambiguous.
it's like the current use of "EXPERIMENTAL" -- choosing to see
features that are EXPERIMENTAL doesn't change the build process in any
way -- it just affects the choices you're allowed to make. it doesn't
*force* you to *take* any of those choices. that's all this new
construct is supposed to do as well.
rday
p.s. if i read simon's earlier patch correctly, all it's doing right
now is allowing assignment of attributes and values to kernel features
-- it does nothing in terms of being able to use that feature in the
config process. that would be step two, after this first step is
added and seems to be correct.
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
Robert P. J. Day wrote:
> *attributes* would be orthogonal to one another -- the values *within*
> an attribute would be mutually exclusive.
Ah, right.
...
> with regard to "experimental", what attribute would you imagine it
> would be a possible value for, and what other possible values might
> that attribute have as opposed to experimental?
In the context of kernel features, "experimental" doesn't mean that
developers are conducting experiments, but rather that users may use it
for experimental purposes. Kernel packagers/ distributors/ admins/
users are advised that this feature is not for use in production (for
whatever reasons, e.g. proof-testing not completed, known instability,
lack of compatibility, missing features).
I have no advise into which attribute to put this and which alternative
values that attribute could assume.
But I can state requirements for the 'experimental' marker, from the POV
of a volunteer driver support guy:
- Show it in big letters in the Kconfig prompt of an experimental
feature.
- Explain at appropriate place(s) what the particular caveats of the
feature are.
That's it. I am not aware of a need to evaluate this marker in routines
which calculate the .config, unlike the 'broken' marker.
BTW, the requirements of communication in feature removal processes are
similar to a degree. But feature removal involves more active two-way
communication and is tied to a schedule.
--
Stefan Richter
-=====-=-=== =--= ----=
http://arcgraph.de/sr/
On Sat, 1 Sep 2007, Jan Engelhardt wrote:
>
> On Aug 31 2007 18:02, Jeff Garzik wrote:
> > Robert P. J. Day wrote:
> >> it may be that some people had a different understanding of what was
> >> meant by "maturity" than i did. what *i* meant by that attribute is
> >> a feature's current position in the normal software life cycle, and
> >> that would be one of:
> >>
> >> experimental -> normal (stable) -> deprecated -> obsolete
> >
> > People who actually write and maintain code disagree with your imaginative
> > interpretation.
>
> Might I point to the "designers and builders" thread...
> http://lkml.org/lkml/2007/8/30/279 :)
i'm trying to figure out whether i fall into the "insane" or the
"hmmm, interesting, we'll get back to you" camp. :-)
http://youtube.com/watch?v=ZF3r5lAvhYI
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
Robert P. J. Day wrote:
> you take advantage of that? you'd have to add a new
> structure to "make config" along the following lines:
>
> Along with maturity-untagged features, what other maturity levels
> would you like to see and be able to select?
Most (all?) users and presumably most distributors/packagers don't
decide this globally. They look at a feature and decide, based on their
need for this feature, whether they enable or disable it, whether they
look into alternative hardware/drivers/apps, whether they get in touch
with the maintainer.
--
Stefan Richter
-=====-=-=== =--= ----=
http://arcgraph.de/sr/
On Sat, 1 Sep 2007, Stefan Richter wrote:
> Robert P. J. Day wrote:
> > *attributes* would be orthogonal to one another -- the values
> > *within* an attribute would be mutually exclusive.
>
> Ah, right.
great, we got that cleared up. onward.
> In the context of kernel features, "experimental" doesn't mean that
> developers are conducting experiments, but rather that users may use
> it for experimental purposes. Kernel packagers/ distributors/
> admins/ users are advised that this feature is not for use in
> production (for whatever reasons, e.g. proof-testing not completed,
> known instability, lack of compatibility, missing features).
>
> I have no advise into which attribute to put this and which
> alternative values that attribute could assume.
at this point, i'm not sure either. given the possible
interpretations of EXPERIMENTAL that i hadn't considered until now,
maybe it really *does* make sense to tag something as both
EXPERIMENTAL and, say, DEPRECATED (does it?). that suggests you might
want to have two orthogonal attributes:
maturity: untagged/normal, DEPRECATED, OBSOLETE
quality(?): untagged/normal, EXPERIMENTAL, BROKEN
obviously, maturity would represent the position in the normal life
span of a feature as it progresses from useful to obsolete, while
quality would identify its perceived quality of code. and those would
(clearly?) be two independent attributes you could apply to any
feature, and be able to select independently.
anyway, this is sort of covered in my earlier post from this morning.
i think.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
Robert P. J. Day wrote:
> given the possible
> interpretations of EXPERIMENTAL that i hadn't considered until now,
> maybe it really *does* make sense to tag something as both
> EXPERIMENTAL and, say, DEPRECATED (does it?).
In theory maybe, for communication purposes perhaps rather not.
The reasoning why a feature is deprecated will typically include the
gotchas which caused the feature to be considered experimental, if such
gotchas still apply.
--
Stefan Richter
-=====-=-=== =--= ----=
http://arcgraph.de/sr/
On Sat, 1 Sep 2007, Stefan Richter wrote:
> Robert P. J. Day wrote:
> > you take advantage of that? you'd have to add a new
> > structure to "make config" along the following lines:
> >
> > Along with maturity-untagged features, what other maturity levels
> > would you like to see and be able to select?
>
> Most (all?) users and presumably most distributors/packagers don't
> decide this globally. They look at a feature and decide, based on
> their need for this feature, whether they enable or disable it,
> whether they look into alternative hardware/drivers/apps, whether
> they get in touch with the maintainer.
agreed. but i'm not proposing that *every* feature in the kernel be
investigated to see what category it falls into -- that's clearly an
unreasonable thing to do.
all this new construct is doing is implementing a new way to globally
select or de-select large sets of kernel features to display for user
selection, in exactly the way that EXPERIMENTAL does it now, that's
all. these attributes would not *force* selection, they would simply
*filter* what to display, nothing more.
this whole attribute thing is not adding anything breathtaking new,
it's simply taking the example set by EXPERIMENTAL and generalizing
it and making it more convenient in the process.
and, as a start, the first thing to do is apply a patch that defines
an attribute and its possible values, and allows kernel features (via
Kconfig files) to be tagged with that attribute, without being able to
do anything with it yet. one step at a time.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
On Sat, 1 Sep 2007, Stefan Richter wrote:
> Robert P. J. Day wrote:
> > given the possible interpretations of EXPERIMENTAL that i hadn't
> > considered until now, maybe it really *does* make sense to tag
> > something as both EXPERIMENTAL and, say, DEPRECATED (does it?).
>
> In theory maybe, for communication purposes perhaps rather not.
>
> The reasoning why a feature is deprecated will typically include the
> gotchas which caused the feature to be considered experimental, if
> such gotchas still apply.
fair enough. there may be times when people won't agree when something
is actually "deprecated." but in cases of actual disagreement, the
easiest solution is to do nothing -- leave that feature untagged, it
won't hurt anything. it would be like arguing about whether something
should currently depend on EXPERIMENTAL. who cares? a user can
simply click on whether they want to see EXPERIMENTAL stuff, anyway.
the places where this makes sense is where everyone agrees that
something is now officially deprecated -- like when it gets its own
entry in the features removal file with a scheduled removal date.
once that happens, it's beyond the point of debate.
but so what if something gets mis-classified every so often? you
always have the ability to ignore all that attribute classification in
the end, anyway. no harm, no foul.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
Stefan Richter wrote:
> But I can state requirements for the 'experimental' marker, from the POV
> of a volunteer driver support guy:
> - Show it in big letters in the Kconfig prompt of an experimental
> feature.
> - Explain at appropriate place(s) what the particular caveats of the
> feature are.
> That's it. I am not aware of a need to evaluate this marker in routines
> which calculate the .config, unlike the 'broken' marker.
Correct.
> BTW, the requirements of communication in feature removal processes are
> similar to a degree. But feature removal involves more active two-way
> communication and is tied to a schedule.
'deprecated' and 'obsolete' are very different beasts from the other
statuses. They are largely just a marker of opinion of the developer,
and are largely treated as synonyms.
Code that was never marked deprecated nor obsolete often appears in
Documentation/feature-removal-schedule.txt, and eventually gets removed.
Feature deprecation and removal is a very amorphous concept that does
not fit well at all into Kconfig markers, unlike experimental/broken.
Jeff
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.
and, as i've said before, i disagree. while one might debate what
those words *mean*, or which features should be tagged thusly, i think
there's a measurable value to be able to, with one mouse click, say
you want to do a build test on the kernel which does not incorporate
anything deemed deprecated and/or obsolete. if you don't agree,
however, no amount of explaining that on my part is going to change
your opinion.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
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.
>
> 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.
Jeff
On Sep 1 2007 11:47, Stefan Richter wrote:
>Robert P. J. Day wrote:
>> given the possible
>> interpretations of EXPERIMENTAL that i hadn't considered until now,
>> maybe it really *does* make sense to tag something as both
>> EXPERIMENTAL and, say, DEPRECATED (does it?).
>
>In theory maybe, for communication purposes perhaps rather not.
devfs would have been a good starting point for
EXPERIMENTAL && (DECPREATED || OBSOLETE).
>The reasoning why a feature is deprecated will typically include the
>gotchas which caused the feature to be considered experimental, if such
>gotchas still apply.
Jan
--
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
Bartlomiej Zolnierkiewicz wrote:
> 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... ;)
I have --no problem-- with changes that enable people to disable
deprecated/obsolete stuff, just like experimental and broken stuff.
I do have a problem with mischaracterization of today's reality.
Jeff
Jan Engelhardt wrote:
> On Sep 1 2007 11:47, Stefan Richter wrote:
>> Robert P. J. Day wrote:
>>> given the possible
>>> interpretations of EXPERIMENTAL that i hadn't considered until now,
>>> maybe it really *does* make sense to tag something as both
>>> EXPERIMENTAL and, say, DEPRECATED (does it?).
>> In theory maybe, for communication purposes perhaps rather not.
>
> devfs would have been a good starting point for
> EXPERIMENTAL && (DECPREATED || OBSOLETE).
Humorous or not, this serves to indicate how synonymous 'deprecated' and
'obsolete' are.
Jeff
Bartlomiej Zolnierkiewicz wrote:
...
> 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.
...
I basically agree. Most people use precompiled kernel packages though.
For them we add kernel log messages, for example. We also preemptively
get in touch with user mailinglists and the like, but we reach only a
fraction of affected people there either.
For people who actually compile kernels, especially distributors, it
would indeed be helpful if "make oldconfig" and Co. show a prompt if an
option entered feature removal schedule. Actually this has been done
before for things like particular sysfs changes, with ad-hoc CONFIG_
variables.
--
Stefan Richter
-=====-=-=== =--= ----=
http://arcgraph.de/sr/
On Sat, Sep 01, 2007 at 05:41:06AM -0400, Robert P. J. Day wrote:
> this whole attribute thing is not adding anything breathtaking new,
> it's simply taking the example set by EXPERIMENTAL and generalizing
> it and making it more convenient in the process.
The problem I see with this whole maturity levels idea is that you've
missed that 'EXPERIMENTAL' is largely a complete failure because
everyone ends up enabling it due to needing something dependant on it.
People just don't care about how mature an option is if they need
a driver/feature. *No-one* is going to come across options and think
"Oh, the driver for my network card isn't stable. Guess I'll not enable it".
And the idea of hiding the options behind multiple levels of
maturity options sounds completely batshit.
Introducing multiple levels of EXPERIMENTAL is just introducing
more symbols of zero value because everyone will end up enabling
them just to get things done.
Dave
--
http://www.codemonkey.org.uk
On Sat, 1 Sep 2007, Dave Jones wrote:
> On Sat, Sep 01, 2007 at 05:41:06AM -0400, Robert P. J. Day wrote:
>
> > this whole attribute thing is not adding anything breathtaking new,
> > it's simply taking the example set by EXPERIMENTAL and generalizing
> > it and making it more convenient in the process.
>
> The problem I see with this whole maturity levels idea is that
> you've missed that 'EXPERIMENTAL' is largely a complete failure
> because everyone ends up enabling it due to needing something
> dependant on it.
i agree. and the reason for that is that people use that qualifier
liberally and never get rid of it. not that long ago, i posted to the
janitors list and suggested that, as a project, people peruse the
source tree and find stuff marked EXPERIMENTAL that's clearly been
stable for years, and remove that dependency. i personally submitted
a patch that removed that qualifier from the ATM stuff.
the *idea* of EXPERIMENTAL is not the problem -- the problem is that
people apply it and ***never take it off again***.
> People just don't care about how mature an option is if they need a
> driver/feature. *No-one* is going to come across options and think
> "Oh, the driver for my network card isn't stable. Guess I'll not
> enable it". And the idea of hiding the options behind multiple
> levels of maturity options sounds completely batshit.
ok. so, at this point, i think it's safe to drop the whole idea,
since more than enough people don't like it or, conversely, they like
it but seem adamant about butchering it badly to the point of
uselessness.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
On Sat, 1 Sep 2007, Robert P. J. Day wrote:
> On Sat, 1 Sep 2007, Dave Jones wrote:
> > People just don't care about how mature an option is if they need
> > a driver/feature. *No-one* is going to come across options and
> > think "Oh, the driver for my network card isn't stable. Guess I'll
> > not enable it". And the idea of hiding the options behind multiple
> > levels of maturity options sounds completely batshit.
by the way and just for the record, dave, you have the above
completely backwards. the default for what you would be allowed to
select or deselect would be *everything*. what this whole maturity
level thing would allow you to do is selectively *deselect* (or
*filter*) what is displayed. in short, if you do nothing, you see no
effect.
so i don't mind folks criticizing the proposal. but it sure would be
nice if they understood what they were criticising, know what i mean?
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
On Sat, Sep 01, 2007 at 02:06:22PM -0400, Robert P. J. Day wrote:
> On Sat, 1 Sep 2007, Robert P. J. Day wrote:
>
> > On Sat, 1 Sep 2007, Dave Jones wrote:
>
> > > People just don't care about how mature an option is if they need
> > > a driver/feature. *No-one* is going to come across options and
> > > think "Oh, the driver for my network card isn't stable. Guess I'll
> > > not enable it". And the idea of hiding the options behind multiple
> > > levels of maturity options sounds completely batshit.
>
> by the way and just for the record, dave, you have the above
> completely backwards. the default for what you would be allowed to
> select or deselect would be *everything*. what this whole maturity
> level thing would allow you to do is selectively *deselect* (or
> *filter*) what is displayed. in short, if you do nothing, you see no
> effect.
>From your earlier mail..
"all this new construct is doing is implementing a new way to globally
select or de-select large sets of kernel features to display for user
selection, in exactly the way that EXPERIMENTAL does it now, that's all."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
EXPERIMENTAL hides options.
> so i don't mind folks criticizing the proposal. but it sure would be
> nice if they understood what they were criticising, know what i mean?
Quite.
Dave
--
http://www.codemonkey.org.uk