Messages in this thread |  | | From | "Eric Bresie" <> | Subject | RE: Request for TODO file | Date | Thu, 12 Oct 2000 15:52:58 -0500 |
| |
> 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/
|  |