Maintainers wanted

[nathany]

I think it makes sense to split fsnotify out into smaller platform-specific libraries that fsnotify (or alternatives) can use. Each library needs maintainers to go off and create the library with integration tests and documentation, and to handle issues and code reviews on an ongoing basis.

• fsevents is one such library, currently in progress (macOS)
• inotify for Linux is another, see proposal: low-level platform-specific packages #173 for my thoughts on it
• Windows also needs a library
• kqueue for BSD (and macOS, iOS)
• poller for Plan9, NFS shares, Sharepoint volumes, etc.
• also FEN for Solaris

Are you interested?

related: https://github.com/pickhardt/maintainers-wanted

letter posted to forum: https://groups.google.com/forum/#!topic/golang-nuts/Ix4sg_gDLNE

[nathany]

I've setup GitHub teams for each platform. If you have already contributed to fsnotify and would like to be added to a platform-specific team, please let myself or another maintainer know.

[zchee]

@nathany Hi,
I had plans to fork fsnotify and integrate the FSEvents because macOS's kqueue have some bugs.

BTW, I would like to confirm just in case,

the best solution I can come up with is to split fsnotify into several platform-specific libraries

Is It means like that?

• fsnotify/inotify
• fsnotify/kqueue
• fsnotify/fsevents

If so and if we want to cross-platform project using fs watcher, Do we will need to import each platform packages to _darwin.go etc and will need to call a different API?

[nathany]

@zchee Initially I'm thinking we build up repositories for https://github.com/fsnotify/inotify, etc. independent of the fsnotify package. Then start replacing the low-level bits of the fsnotify package with dependencies on those, while maintaining the same cross-platform API.

Eventually we can also substitute kqueue for fsevents on darwin.

If you'd like to help out, take a look at the https://github.com/fsnotify/fsevents project. There is an open issue with some next steps there, and I'm sure there's much more to do.

[zchee]

@nathany Ah, I see. Thanks.
So, split the repository by each of the platforms, and will add an API to integrate them on the fsnotify, right?

Anyway, Apple has been announced apfs(Apple File System) and scheduled for release in 2017. Maybe filesystem interface also will change.
I'll help you as much as possible.

[tiwaana]

I like the idea but I am not sure how closely linux and windows interfaces are ?

[nathany]

They are quite different. Right now I'm not thinking of changing the API of fsnotify. Just keep it stable for users.

If we can separate the code into low-level bits and high-level bits, I think it will be easier to maintain, as separate teams of people will be able to focus on each platform, with one team on cross-platform concerns.

Not sure if I'm explaining it well, it might be easier to show than explain.

I've already started with kqueue, where the code from line 463 on is the low level part. https://github.com/fsnotify/fsnotify/blob/master/kqueue.go#L463. I'm thinking of putting that in a separate repo with a test suite and documentation and making that into it's own library that fsnotify depends on.

Still many details to work out though -- and certainly open to other ideas.

[zchee]

@nathany Ah, it's for me? If so, I totally understood. Yes, API compatibility is very important. and I like your idea.

I incorrectly wrote it. Not "add" an API to the fsnotify.
I am terribly sorry to have caused confusion.

[nathany]

I could still really use some help to maintain fsnotify. Code reviews, testing and merging PRs, doing releases.

[nathany]

Clearly I have been doing a poor job of maintaining fsnotify. Issues without answers, pull requests left open for months... progress has stalled not due to lack of contributors, but because I am currently the bottleneck.

When I got involved with Chris Howey's fsnotify, it was to help out with the API. I don't have the experience and knowledge of file systems necessary to vet a pull request like #124, which adds epoll to kqueue. Much less take on a whole new platform like #196. At first I thought I would learn these things, but doing so hasn't been a priority in what spare time I do have.

I had hoped that having a generous policy (#126) for granting commit access combined with this call for maintainers would see a team of people volunteer to help maintain fsnotify. I had high hopes for splitting responsibility by operating system to make maintenance more palatable. But that hasn't happened... and I don't know what needs to be done for that to happen.

At this point, I am tired of feeling guilty for not being more involved in the project. I'm also tired of worrying that merging a pull request will break an upstream like Docker or a platform that isn't under CI (#136).

I haven't been very involved lately, so it's time to make it official. I'm stepping away from the fsnotify project. It's up to you now.

If you need something from me during the transition, reach out to me here or on #fsnotify on Slack. Good luck.

[zchee]

@nathany Hi,
Just one thing, I just wanna tell you that you did the job is not poor.
The community(and Member) management, raise a problem of members shortage is very hard work. Not poor.

Sorry for my pull request was related the CI only. But I'll more learn the file-systems, and I will make an effort to contribute to the linux side(if possible). I'll do my best.

[samjacobson]

@nathany Thanks for all of your work! You've done a great job running this project, and coaxed contributions from many people (including myself), and found a way to piece them all together. You deserve thanks from all the many people who have benefitted. Good luck with whatever you do next! Sam

…

On Wed, Mar 15, 2017 at 10:36 AM, Koichi Shiraishi ***@***.*** > wrote: @nathany <https://github.com/nathany> Hi, Just one thing, I just wanna tell you that you did the job is not poor. The community(and Member) management, raise a problem of members shortage is very hard works. Sorry for my pull request was related the CI only. But I'll more learn the file-systems, and I will make an effort to contribute to the linux side(if possible). I'll do my best. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#183 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABMJvdHHp0Bfkeaf6u9w0A65fqnsMbS1ks5rlwhagaJpZM4KgPzl> .

[nathany]

Relevant: https://github.com/blog/2392-introducing-code-owners

[nathany]

If you're planning to be at GopherCon in Denver next week, and if you have been helping or would like to help maintain fsnotify, let's plan to meet on Community Day.

[kolyshkin]

I can step up as a maintainer.

• pros: interest in this package, experience in Go and as a maintainer (opencontainers/runc, moby/moby).
• cons: lack of Windows / Mac OS X experience, lack of time.

[nathany]

@kolyshkin Thanks Kir. That would be really helpful. Even just to have someone focused on the inotify portion and to help triage pull requests and issues. Cross-platform experience is only necessary if we want to change the API.

[nathany]

There's a call for gophers to help here: gofrs/help-requests#15

[nshalman]

Relating to my work on #371 I am open to becoming a maintainer for the FEN support for solaris/illumos.

[nathany]

@nshalman Thanks! Invite sent.

[Lumexralph]

Hi @nathany Do you still need help maintaining fsnotify ?

[nathany]

@Lumexralph Yes

It's a challenging project, to be sure, being a cross-platform API to unify disparate APIs makes it tricky.

[nathany]

My call for help maintaining fsnotify has had very little result in the past 5 years.

I will be officially leaving the fsnotify project whether or not anyone else picks it up.

If nobody else takes the project over soon, I will be archiving the project. That way it can still be used as-is but no more issues can be reported.

[nathany]

There are a lot of open issues, and a lot of them are duplicates. I've updated the issue template to hopefully cut down on future duplicates, but someone still needs to reply to existing issues.

Better documentation may also help preemptively answer questions that people keep reporting issues for again and again.

[nathany]

replaced issue with #413