Re: Future of libfuse maintenance

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

 





On 1/29/24 13:46, Antonio SJ Musumeci wrote:
On 1/29/24 03:22, Bernd Schubert wrote:
Hi Nikolaus,

On 1/29/24 09:56, Nikolaus Rath wrote:
[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.

firstly. thanks a lot for your great work over the last years!


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).

Please not, that is quite dangerous. I don't think the tests are
perfect, especially with compatibility tests are missing. In principle
we would need to get github to run tests on different kernel versions -
no idea how to do that.



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.

I'm maintaining our DDN internal version anyway - I think I can help to
maintain libfuse / take it over.

Btw, I also think that kernel fuse needs a maintenance team - I think
currently patches are getting forgotten about - I'm planning to set up
my own fuse-bernd-next branch with patches, which I think should be
considered - I just didn't get to that yet.


Thanks,
Bernd

+1 for Bernd's maintenance *team* idea. But perhaps extended to libfuse
as well? There are a number of us who are familiar with the code and at
least semi-active in the space. Help spread the load.

I could help out at least on the libfuse side.

You are absolutely right, a team is always better.




[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