On Thu, Apr 26, 2018 at 07:58:52AM +0300, Nikolay Borisov wrote: > > > On 25.04.2018 23:30, David Sterba wrote: > > On Wed, Apr 25, 2018 at 08:46:02AM -0700, Matthew Wilcox wrote: > >> Recently ncpfs got moved to staging. Also recently, we had some fuzzer > >> developers report bugs in hfs, which they deem a security hole because > >> Ubuntu attempts to automount an inserted USB device as hfs. > >> > >> We have no maintainer for hfs, and no likely prospect of anyone stepping > >> up soon to become hfs maintainer. I think it's irresponsible of us > >> to present unmaintained code on an equal basis with filesystems under > >> active maintenance like ext2. > >> > >> I therefore propose we move the following filesystems which are explicitly > >> listed as Orphaned to staging: > >> > >> affs - Amiga filesystem. > >> efs - old SGI filesystem predating XFS, used on CDs for a while. > >> hfs - Mac filesystem. > >> hfsplus - Mac filesystem. > >> > >> I further propose we move the following filesystems which have no entry > >> in MAINTAINERS to staging: > >> > >> adfs - Acorn filesystem from the 1990s. > >> minix > >> qnx6 > > > > I had similar toughts some time ago while browsing the fs/ directory. > > Access to the filesystem images can be reimplemented in FUSE, but other > > than that, I don't think the in-kernel code would be missed. > > > > It's hard to know how many users are there. I was curious eg. about bfs, > > befs, coda or feevxfs, looked at the last commits and searched around > > web if there are any mentions or user community. But as long as there's > > somebody listed in MAINTAINERS, the above are not candidates for moving > > to staging or deletion. > > > > I think the presence of maintainers entry is necessary but insufficient. > What if the maintainer has long lost interest but just didn't bother > updating the file. In the very least maintainers should be pinged and > asked if they are still maintaining the respective piece of code. That's a good point. However the age of the last commit must not be used as an excuse for moving them, because if the few users are very happy with the code, never meet corner cases and never have to report bugs, neither them nor the maintainers should be punished. In my opinion the only two reasons for deprecating or removing code are that it's not maintained anymore or that it's using ancient infrastructure that needs to be changed and there's no way to adapt the old code to the new one. In fact I think that the problem with very silent maintainers goes way beyond FS. Everyone in MAINTAINERS who didn't send a commit in one year should probably be asked if they're still doing the work, if they'd be interested in someone else taking over, or if they think the whole code has no reason to continue to exist. Willy
