Re: [PATCH] add feature-removal-schedule.txt documentation

[Greg KH]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/