at the risk of spawning yet another thread and another flamefest,
what *are* the kernel features that should be considered candidates
for removal, either now or at some point in the future.
please, no discussions about mechanisms or kernel warnings or the
like -- just the features whose value is nearing their end. i'll even
volunteer to collect all that info and summarize it here:
http://fsdev.net/wiki/index.php?title=Stuff_to_be_removed
because that's just the kind of guy i am, and i have the week off, and
i'm bored. :-)
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
Robert P. J. Day wrote:
> at the risk of spawning yet another thread and another flamefest,
> what *are* the kernel features that should be considered candidates
> for removal, either now or at some point in the future.
>
> please, no discussions about mechanisms or kernel warnings or the
> like -- just the features whose value is nearing their end. i'll even
> volunteer to collect all that info and summarize it here:
>
> http://fsdev.net/wiki/index.php?title=Stuff_to_be_removed
>
> because that's just the kind of guy i am, and i have the week off, and
> i'm bored. :-)
>
> rday
>
Already documented in the kernel tarball, see
Documentation/feature-removal-schedule.txt
On Tue, 01 May 2007 17:30:36 +0200, Andre Tomt said:
> Robert P. J. Day wrote:
> > http://fsdev.net/wiki/index.php?title=Stuff_to_be_removed
> Already documented in the kernel tarball, see
> Documentation/feature-removal-schedule.txt
Robert's point is that the file you cited is horrendously out of date, and
we need to create a consensus of what *should* be in feature-removal-schedule.txt
so we can update it to correspond to some sort of reality, or at the very least
some politically correct sanitized view of reality. It currently lists
stuff scheduled to be removed 18 months ago, and doesn't list stuff that
everybody agrees deserves to be heaved over the side as soon as the users have
had "enough warning" (whatever that means)....
On May 1 2007 11:01, Robert P. J. Day wrote:
>
> at the risk of spawning yet another thread and another flamefest,
>what *are* the kernel features that should be considered candidates
>for removal, either now or at some point in the future.
>
> please, no discussions about mechanisms or kernel warnings or the
>like -- just the features whose value is nearing their end. i'll even
>volunteer to collect all that info and summarize it here:
>
>http://fsdev.net/wiki/index.php?title=Stuff_to_be_removed
>
>because that's just the kind of guy i am, and i have the week off, and
>i'm bored. :-)
You could work on the menuconfig objects - I don't think I was done. :p
Jan
--
[email protected] wrote:
> On Tue, 01 May 2007 17:30:36 +0200, Andre Tomt said:
>> Robert P. J. Day wrote:
>
>>> http://fsdev.net/wiki/index.php?title=Stuff_to_be_removed
>
>> Already documented in the kernel tarball, see
>> Documentation/feature-removal-schedule.txt
>
> Robert's point is that the file you cited is horrendously out of date, and
> we need to create a consensus of what *should* be in feature-removal-schedule.txt
> so we can update it to correspond to some sort of reality, or at the very least
> some politically correct sanitized view of reality. It currently lists
> stuff scheduled to be removed 18 months ago, and doesn't list stuff that
> everybody agrees deserves to be heaved over the side as soon as the users have
> had "enough warning" (whatever that means)....
It means to get in touch with people who are affected. Yes, that's the
tough part.
Regarding features that are overdue for removal according to
feature-removal-schedule.txt:
I remember that at least one person used to watch for due dates for
feature removal, wrote the removing patches, and sent them to the
appropriate lists and maintainers. This either got rid of the obsolete
stuff, or it turned up reasons why some feature could not be removed
just yet and how to update feature-removal-schedule.txt to correctly
reflect that.
So, as they say, Patches Are Welcome.
--
Stefan Richter
-=====-=-=== -=-= ---=-
http://arcgraph.de/sr/
On Wed, 2 May 2007, Stefan Richter wrote:
> Regarding features that are overdue for removal according to
> feature-removal-schedule.txt:
>
> I remember that at least one person used to watch for due dates for
> feature removal, wrote the removing patches, and sent them to the
> appropriate lists and maintainers. This either got rid of the
> obsolete stuff, or it turned up reasons why some feature could not
> be removed just yet and how to update feature-removal-schedule.txt
> to correctly reflect that.
>
> So, as they say, Patches Are Welcome.
that's a nice idea, but it doesn't address the problem that someone
might go to the trouble to create such a patch and send it in, only to
have that submission generate shrieking along the lines of "OHMIGOD,
we can't delete that *yet*!!!"
that's the whole point of this wiki page:
http://fsdev.net/wiki/index.php?title=Stuff_to_be_removed
it's meant for active participation to converge on a *consensus* as to
what should go and what shouldn't, *after* which the features removal
file can be updated appropriately and patches can start to be
generated.
it's incredibly wasteful to take the time to create and submit a
feature removal patch that ends up just *establishing* that something
shouldn't be deleted yet. i'm sure most people here can think of
better things to do with their time.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
Robert P. J. Day wrote:
> On Wed, 2 May 2007, Stefan Richter wrote:
>
>> Regarding features that are overdue for removal according to
>> feature-removal-schedule.txt:
>>
>> I remember that at least one person used to watch for due dates for
>> feature removal, wrote the removing patches, and sent them to the
>> appropriate lists and maintainers. This either got rid of the
>> obsolete stuff, or it turned up reasons why some feature could not
>> be removed just yet and how to update feature-removal-schedule.txt
>> to correctly reflect that.
>>
>> So, as they say, Patches Are Welcome.
>
> that's a nice idea, but it doesn't address the problem that someone
> might go to the trouble to create such a patch and send it in, only to
> have that submission generate shrieking along the lines of "OHMIGOD,
> we can't delete that *yet*!!!"
You are absolutely right.
We have to try to avoid this waste of resources when we put features
into feature-removal-schedule.txt. That's what I meant with "the hard
part" in the other post.
BTW, of course it doesn't suffice to say "we can't remove it yet" after
the due day. There need to be well-founded reasons for another
deferral. Of course if there are such reasons, it means something went
wrong when the feature was put into removal schedule. (Some facts
weren't known.)
> that's the whole point of this wiki page:
>
> http://fsdev.net/wiki/index.php?title=Stuff_to_be_removed
Yep; if that page helps to collect the facts, then all the better.
Though in the very end, a feature goes away by means of a patch.
[...]
> i'm sure most people here can think of better things to do with their
> time.
Funny (or not so) how this sentence applies to all kinds of activities
into which more than one person is involved. So let's try to plan our
work carefully and *timely*, to let as little of it go to waste as possible.
--
Stefan Richter
-=====-=-=== -=-= ---=-
http://arcgraph.de/sr/
> >> Regarding features that are overdue for removal according to
> >> feature-removal-schedule.txt:
> >>
> >> I remember that at least one person used to watch for due dates for
> >> feature removal, wrote the removing patches, and sent them to the
> >> appropriate lists and maintainers. This either got rid of the
> >> obsolete stuff, or it turned up reasons why some feature could not
> >> be removed just yet and how to update feature-removal-schedule.txt
> >> to correctly reflect that.
> >>
> >> So, as they say, Patches Are Welcome.
> >
> > that's a nice idea, but it doesn't address the problem that someone
> > might go to the trouble to create such a patch and send it in, only to
> > have that submission generate shrieking along the lines of "OHMIGOD,
> > we can't delete that *yet*!!!"
>
> You are absolutely right.
>
> We have to try to avoid this waste of resources when we put features
> into feature-removal-schedule.txt. That's what I meant with "the hard
> part" in the other post.
>
> BTW, of course it doesn't suffice to say "we can't remove it yet" after
> the due day. There need to be well-founded reasons for another
> deferral. Of course if there are such reasons, it means something went
> wrong when the feature was put into removal schedule. (Some facts
> weren't known.)
So when this sort of thing comes up, why can't somebody put together a
trivial patch to update feature-removal-schedule.txt? If a deadline is
reached, and a removal is attempted and aborted, the deadline should be
extended, obviously. So then the patches can be resubmitted (or recreated,
even) when the new deadline is reached, da capo.
John Anthony Kazos Jr. wrote:
[I wrote]
>> BTW, of course it doesn't suffice to say "we can't remove it yet" after
>> the due day. There need to be well-founded reasons for another
>> deferral.
[...]
> So when this sort of thing comes up, why can't somebody put together a
> trivial patch to update feature-removal-schedule.txt? If a deadline is
> reached, and a removal is attempted and aborted, the deadline should be
> extended, obviously. So then the patches can be resubmitted (or recreated,
> even) when the new deadline is reached, da capo.
<stating_the_obvious>
Yes, of course. When a decision is reached to defer or even abort a
feature removal process, the maintainer in charge should take care that
such an updating patch goes to feature-removal-schedule.txt.
So if there are outdated entries in feature-removal-schedule.txt, then
it's because someone forgot something, and it won't hurt to ask the
responsible person if he knows of a change in the removal plan.
</stating_the_obvious>
--
Stefan Richter
-=====-=-=== -=-= ---=-
http://arcgraph.de/sr/
On Wed, 2 May 2007, John Anthony Kazos Jr. wrote:
> stefan richter wrote:
> > We have to try to avoid this waste of resources when we put
> > features into feature-removal-schedule.txt. That's what I meant
> > with "the hard part" in the other post.
> >
> > BTW, of course it doesn't suffice to say "we can't remove it yet"
> > after the due day. There need to be well-founded reasons for
> > another deferral. Of course if there are such reasons, it means
> > something went wrong when the feature was put into removal
> > schedule. (Some facts weren't known.)
>
> So when this sort of thing comes up, why can't somebody put together
> a trivial patch to update feature-removal-schedule.txt? If a
> deadline is reached, and a removal is attempted and aborted, the
> deadline should be extended, obviously. So then the patches can be
> resubmitted (or recreated, even) when the new deadline is reached,
> da capo.
argh. the whole point of this discussion is to come to a *consensus*
on what should be in that feature removal file. there is no point in
creating and submitting patches, either to update that file or remove
kernel features, until enough people *agree*.
at the risk of being head-bangingly repetitive, that's what the wiki
page is for:
http://fsdev.net/wiki/index.php?title=Stuff_to_be_removed
go. read. comment. update. add. remove. it's a wiki. don't make
me pull this car over and explain it. :-)
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
On Wednesday May 2, [email protected] wrote:
> On Wed, 2 May 2007, John Anthony Kazos Jr. wrote:
>
> argh. the whole point of this discussion is to come to a *consensus*
> on what should be in that feature removal file. there is no point in
> creating and submitting patches, either to update that file or remove
> kernel features, until enough people *agree*.
>
> at the risk of being head-bangingly repetitive, that's what the wiki
> page is for:
>
> http://fsdev.net/wiki/index.php?title=Stuff_to_be_removed
>
> go. read. comment. update. add. remove. it's a wiki. don't make
> me pull this car over and explain it. :-)
Unfortunately, this community is not founded on the concept of
'wiki'. It is founded on the concept of 'email'. That is were most
discussions happen.
So if you want to start a discussion (and your topic certainly seems
relevant) I suspect you will get more participation if you keep it in
the mailing list.
So post a list of features that are apparently due for removal and ask
"can I actually get rid of these" (or whatever you want to ask). and
then base on the response, do something else, maybe a revised list,
maybe a patch, maybe send it again in CAPITALS because nobody notice
when it was in lower-case :-)
Wiki's certainly have there place, but I don't think this is it.
NeilBrown
On Wed, 2 May 2007, Neil Brown wrote:
> Unfortunately, this community is not founded on the concept of
> 'wiki'. It is founded on the concept of 'email'. That is were most
> discussions happen.
>
> So if you want to start a discussion (and your topic certainly seems
> relevant) I suspect you will get more participation if you keep it
> in the mailing list.
you have it backwards -- i deliberately chose a wiki to get this
discussion *off* the LKML. given the traffic volume here, and given
that kernel code removal isn't what most people consider a high
priority, i'm guessing most folks here are monumentally uninterested
in the discussion.
thus, a wiki gives the people who are still interested a place for all
that info, while uncluttering the LKML. and if some discussion gets
really heated, *then* the LKML can be used to resolve it.
as it is, i think this issue has been flogged adequately on this
mailing list, and it can safely be moved elsewhere where people who
care about it can still get to it.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
Robert P. J. Day wrote:
> On Wed, 2 May 2007, Neil Brown wrote:
>
>> Unfortunately, this community is not founded on the concept of
>> 'wiki'. It is founded on the concept of 'email'. That is were most
>> discussions happen.
>>
>> So if you want to start a discussion (and your topic certainly seems
>> relevant) I suspect you will get more participation if you keep it
>> in the mailing list.
>
> you have it backwards -- i deliberately chose a wiki to get this
> discussion *off* the LKML. given the traffic volume here, and given
> that kernel code removal isn't what most people consider a high
> priority, i'm guessing most folks here are monumentally uninterested
> in the discussion.
[...]
IMO you are both right and wrong in your own ways.
I agree with Neil that you* have to go to the people who are concerned.
I agree with you that LKML will often not be the place where you* find
them. (Still, you* have to find them; it's not that they have to find
your wiki discussion.)
*) "you" = whoever has the drive and persistence, and is connected
enough with the communities to help in feature removal processes
--
Stefan Richter
-=====-=-=== -=-= ---=-
http://arcgraph.de/sr/