Messages in this thread | | | Date | Fri, 7 Jan 2005 10:11:31 -0800 | From | Greg KH <> | Subject | Re: [PATCH] add feature-removal-schedule.txt documentation |
| |
On Fri, Jan 07, 2005 at 09:54:16AM -0800, Linus Torvalds wrote: > > > On Fri, 7 Jan 2005, Randy.Dunlap wrote: > > > > Brodo, can you add a little more info to this, please? > > I think for something like this to be really useful, you should not just > say "can be replaced with Xxxx", but have some docs (or pointers to such) > for both users and developers (depending on who is affected) on _how_ to > replace it, or fix it. > > Also, I'm not convinced about the single-file format. If we want to do > this (I don't know how much it buys, but hey, I certainly also don't have > any objections), I think it would be much nicer to have a separate > "deprecated" subdirectory, with one file per issue.
Ok, that's fine with me, makes it easier for patches. I'll take my writeup and Randy's and split them out.
> (Not that I think it necessarily needs to be just about deprecated or > removed features - again, if we do this, I don't see why it shouldn't > contain the same information about semantic changes, so that when the > locking for an interface changes, you could have a > > Documentation/changes/vfs-ioctl-locking.txt > > that tells what the new rules are).
Hm, but things "change" all the time. "new" rules become "old" rules over time too. What should probably happen is the proper rules are documented and kept up to date, like they are today in Documentation/filesystems/Locking and Documentation/pci.txt as two examples. Showing what has changed over time in those two files is what diffs are for :)
Otherwise, the kernel changelogs are good places to dig for changes in apis, but do we really want to duplicate this in other places too?
thanks,
greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |