> From: tytso@mit.edu [mailto:tytso@mit.edu]
> Sent: Wednesday, October 11, 2000 5:43 PM
>
> I've taken a look at that list, and it looks fairly obsolete, as far as
> I could tell. There is an actively maintained list which I post
> periodically to the Linux-Kernel mailing list, and which is also
> available at:
>
> www://linux24.sourceforge.net
Thanks for the info about this link...I never can seem to keep up with
all the good linux kernel links like that one. You are doing a great job.
Can I suggest a thing or two:
* Include a small TOC with links to the corresponding section in the doc.
* Have some predefined keywords that might be useful for searching through
the file; example: (keyword: NFS FS)
* Include some form of platform identification (platform: ALL, ix86,
PPC,etc)
Some of these might even be useful as some XML tags...but that's a whole
different thread.
> From: "Eric Bresie" <ebresie@usa.net>
> Date: Mon, 9 Oct 2000 15:31:56 -0500
> I was looking through the current versions of the kernel, was
re-reading
> through some past "TODO before release" sort of messages, and was
wondering,
> could these TODO type of items be included in an actual TODO file at
the
> source top level (or in the Documentation if this would be more
appropriate)
> and/or included in each level like some of the other areas, (like fs)
areas
> seem to have? Either that or move all the TODO into the top level one,
with
> the top level being segmented to the areas of relevance (like a mm, fs,
etc
> sections).
>
> The problem is that it's easier for the list to be maintained when it's
> outside of the kernel tree; it means that bugs can get added to it
> without waiting for the next kernel rev, for example. (I only
> periodically post an updated list to the L-K list, but the linux24
> webpage gets updated more frequently than that.)
Well...my reason for suggesting it though, is because if we keep the TODO as
part of
the actual kernel tree...we can maintain a mapping of known problems and
tasks that
related to a given kernel.
How is maintaining it as a TODO/Changes file within the kernel tree any
different then a file in the kernel tree itself?
If an individual, fixes, say a driver for a given type of sound card, the
person could give a brief, "This driver has been fixed comment" (maybe even
taken from some kind of cvs type comment for the update), remove the "Needs
to be fixed", then do the corresponding patch creation including the TODO
and/or Changes file as part of the files to patch.
I would guess the only possible problem might be getting people into the
habit of changing the TODOs and/or Changes.
The benefit of this of couse, is that more than one person can work on it at
a time. Although I still think at least one person should monitor it (and
even clean it up regularly). That person would every so often, remove
previously fixed bugs after the next release is available, to avoid run away
TODO files sizes.
> I do keep the fixed bugs at the bottom of the list, but it's probably at
> a level of detail which is *far* more detailed than what you would want
> to see in the top-level Changes file in the kernel.
>
> - Ted
Eric Bresie
ebresie@usa.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:23 EST