Future of libfuse maintenance

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[Resend as text/plain so it doesn't bounce from linux-fsdevel@]

Hello everyone,

The time that I have availability for libfuse maintenance is a lot less today than it was a few years ago, and I don't expect that to change.

For a while, it has worked reasonably well for other people to submit pull requests that I can review and merge, and for me to make regular releases based on that.

Recently, I've become increasingly uncomfortable with this. My familiarity with the code and context is getting smaller and smaller, so it takes me more and more time to review pull requests and the quality of my reviews and understanding is decreasing.

Therefore, I don't think this trajectory is sustainable. It takes too much of my time while adding too little value, and also gives the misleading impression of the state of affairs.

If anyone has ideas for how libfuse could be maintained, please let me know.

Currently I see these options:

1. Fully automate merge requests and releases, i.e. merge anything that passes unit tests and release every x months (or, more likely, just ask people to download current Git head).

2. Declare it as unmaintained and archive the Github project

3. Someone else takes over my role. I'd like this to be someone with a history of contributions though, because libfuse is a perfect target for supply chain attacks and I don't want to make this too easy.

Best,
-Nikolaus




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux