Looking for maintainers

[passcod]

As per the abandonment announce, copied here for convenience:

Notify has been years of my life and as much as it’s a tough decision, I’m also greatly relieved. It’s been great, it’s been not so great; it’s now time. I got some distance, took a hard look at it all, and realised I don’t want to do this any more. For way longer than I should have let this go on for, Notify sparked negative joy, and I’m Marie-Kondo-ing it out.

The logistics: several people have commit bit, and several people have publish bit, and the project is also covered by the Rust Bus.

If you want to take over or get commit/publish bits and you’re a trusted/respected community member, just ask. If you’re not a trusted/respected community member, try forking first.

I will not merge PRs, I will not commit unless it’s an emergency, I will not respond to issues or comments unless I really really feel like it, and the goal is total disengagement.*

So Long 🔭 And Thanks For All The Fish 🐬

* As an addendum, though, I'm happy doing some light admin and light mentoring / answering questions about current and future design and code, during the transition period, as long as that takes.

There's also some comments on Twitter:

• at the original announce: https://twitter.com/passcod/status/1168188637361725442
• at this quoting thread: https://twitter.com/yaahc_/status/1168217915285372928

@Dylan-DPC has expressed some interest in helping to create an organisation and taking this forward.

This is a call for anyone else who would be interested in maintainership!

[Dylan-DPC-zz]

If you want to help contributing to this crate, please leave a comment below

[passcod]

I can also hand over the repo and crate to @rust-unofficial if that's a better venue, especially for a crate which may have community importance (as it's used in many projects). /cc @badboy

[0xpr03]

I'm interested in getting 5.0 over the edge. I can try to help if pointed towards issues.
Edit: Due to own private OSS software taking huge time I'm unfortunately not able to become a maintainer (at least not alone or primary ).

[passcod]

There's no nearby edge for 5.0. OK. So, for people, here's a quick view of what was in my head for 5.0 and further. Obvi no need to adhere to all or part of it.

• From 0 to 4, the event type was essentially a bitfield, hence it could contain many different kinds of events on the same structure, but it's very limited in what it could express. Further, the event type was a simplification of the inotify native bitfield, so it was kinda fit for that, and then other native api event semantics were retrofitted on top. Kind of a mess. So I redesigned the event type to only contain one semantic action at a time, and have a hierarchical structure that covers more than all native systems I looked at combined, with possibility for expansion in several ways. Then there's a Vec of PathBufs, so events can describe that they apply to several paths, with semantics left in the air here at this point (the thinking being that for most events it should be length == 1, but for renames where both sides are known it would be [original, new]).
• The original idea with the new event type was that it would go in the next branch of notify, which was a complete rewrite. However, I started to burn out, and at some point figured that the next branch would likely never get finished at that rate, so I may have better luck retrofitting the finished parts of Next onto the existing code, as a kind of transitive step and to rebuild momentum.
• That posed a larger problem that I didn't immediately realise. All the old code works on the assumption that events may contain multiple event kinds. There's various manipulations here, e.g. we can transform one event into another by adding in the bit for the new type and then later remove the bit for the old type, sometimes in completely different parts of the code, with potentially complex interactions in between. And often, the code expected one event to go in, and one event to go out, and the in and out could have any amount of actual semantic actions on them.
• There were also bigger issues I could start to see take shape with how the debounce code worked. But anyway, what I did was I ripped out all that I could see of the debounce code and got 5.0 with only immediate API mostly working.
• So the first step is to remake the debounce code for 5.0. There's many approaches and idk which is good, so I won't comment on that. Just one thing would be that I believe not looking at the old impl and docs when doing the initial design work would be beneficial, to create something that follows expectations rather than legacy.
• Second step is to integrate or re-integrate the new options system that was made for the OngoingEvents feature.
• Third step, which may be better done interleaved with 1&2 is to make the NoticeEvents an optional feature as per this option system.
• Four is to hide event type unless the PreciseEvents option is on.
• Five is to review and get a stable release out.
• Six is to get a 5.1 with the new channel-less API as in the readme, or as per @matklad's last suggestion in Use crossbeam-channel instead of stdlib #160. (done in Remove channel in favour of accepting Fn in Watcher constructors #214)
• Seven is to get a 5.2 with precise events filtered at the kernel level if/when possible? dunno.
• Then there's the stretch goals later of:
  • Adding a watchman backend
  • Fixing all bugs lol

That's it! Enjoy

Edit: ok that's not quite it

Here's unsorted thoughts on versions 6 and more:

• Make a new backend that uses kevent that works on both bsd (woo mire platform support) and macos. Evaluate that latter support to see if it can handle workloads, then eventually switch out the default macos backend to kevent. There's various issues and comments in places that explain why.
• Make a thing that can select a backend at runtime. This is both for the macos kevent/fsevent divide, and for the watchman backend (need to detect a ready and controllable watchman socket), and further backends later. Don't bother with dynamic fallback at this point, just return a configured impl Backend.
• Part of the api in the readme is that one can spin up two notify instances on the same channel to get different option sets! Maybe some ergonomics or wrapping work around that, depending on how it looks.
• Sometime into the future (maybe a year out to give the ecosystem time to stabilise?) look into using futures/async internally
• Make a C interface. Optionally add other bindings (node with neon, etc) that may benefit from a more direct api translation rather than going through the C api. There's going to be interesting challenges around event type and delivery here.
• A big work would be dynamic backend switching and/or composite backends. That means putting a layer on top that can manage the paths watched and make sure there is at least one backend on it, watching the event streams per backend to detect when a backend is dropping (e.g. from capacity, or because the watchman daemon shuts down, etc) and reconfiguring backends to cover paths, probably issue meta events in the output stream when backends change to indicate potential gaps, and error events when a path can't be watched at all at the moment, etc
• a cool feature could be a network protocol to expose notify over a socket, both for re-ingestion by another notify, and for other tools. Could do things like privileged daemons and non-priv tools

Edit 2: almost forgot: at some point one might also want to add some tests back because they're kinda all gone oops

[passcod]

There's a bugfix fork by @ashleygwilliams https://github.com/ashleygwilliams/notify released as notify-forked — not for feature work

[mitchmindtree]

Thanks for all your work @passcod! It's a real shame to see you stop work on this but I totally understand - I feel you!

Many of the listed issues for reaching 5.0 seem to be related to the higher-level Event type and the state machine involved in interpreting RawEvents into these higher-level events. I personally have never used the higher-level Event type in downstream projects and tend to use the RawEvents directly, though my projects using notify are normally pretty small and typically involve hotloading a small crate or some GLSL on any kind of file change.

That said, I wonder if it might be worth stripping down notify to its lower-level, cross-platform RawEvent handling and then create another crate which provides an API for feeding notify::RawEvents into a state machine to interpret them and produce higher-level, "debounced" Events? Perhaps this could potentially ease the burden slightly for folks considering contributing or taking on maintainership? It might also make it a little easier to stabilize the cross-platform, lower-level parts of notify while deliberation continues on how to present a nice higher-level event API?

Apologies if there's already an open issue for this that I have missed! Best wishes for your notify break :)

@Dylan-DPC I like the idea of creating a dedicated organisation along the lines of notify-devs for managing notify. Perhaps this way it might make it easier for multiple folks to share the maintenance burden?

[passcod]

The point of the new Event type is to be the low level, the high level, the only level, as the old RawEvent were, as stated, a limited derivation of the inotify bit field, without regard for the rest of the backends, because that's how notify started. There is no interpreting RawEvents into anything, the current state of 5.0 already emits the new event type directly from translation off the relevant kernel interface and I'm pretty sure I eradicated the RawEvent type from the code. At the high level, as you can see from your own uses, it was the plan to make PreciseEvents opt-in... That is, that the only output would be an event per file changed, without reporting *what* that change is, which is what most care about: "hi, this file changed, do what you will". Furthermore, while v4 had two event types, as you say, a low level RawEvent and a higher level debounced Event, the other point behind a much more generic new event type was to get rid of this difference altogether. One event type instead of two. Two nice bonuses come of that: - it becomes trivial to switch from raw/immediate to debounced or vice versa, which would be great not only for debugging and bug hunting (how many times have i said "please try with raw mode"...) but also possibly for downstream applications who want to optionally turn off deboucing. - you can hook up a debounced notify and a raw/immediate notify to the same channel at the same time. Like say you're watching a project with a debounce but after an action you want to get a notification *right when a particular file is changed*, well, instead of separate machinery you could start an immediate watcher on the same channel and then tell it to watch that one file only when you need. NoticeEvents were one solution, this perhaps a simpler one that can only work if the event types are the same, but also can be much better targetted. For debugging this is also great, as you can just see what's happening under both debounced and immediate modes simultaneously, with no changes to your code which may obscure the real bug. The current release of 5.0 is pretty much exactly what you're suggesting. It has no debouncing code, and only exposes the raw events. Debouncing as a layer on top is probably best, but not my call anymore ;) These are, after all, the perks of abandonment: I can tell y'all what was in my head (or try, at least), but just like I'm not going to do anything about it, y'all can ignore any or all of it and go about your own way.

…

On Fri, 13 Sep 2019, 17:24 mitchmindtree, ***@***.***> wrote: Thanks for all your work @passcod <https://github.com/passcod>! It's a real shame to see you stop work on this but I totally understand - I feel you! Many of the listed issues for reaching 5.0 seem to be related to the higher-level Event type and the state machine involved in interpreting RawEvents into these higher-level events. I personally have never used the higher-level Event type in downstream projects and tend to use the RawEvents directly, though my projects using notify are normally pretty small and typically involve hotloading a small crate or some GLSL on any kind of file change. That said, I wonder if it might be worth stripping down notify to its lower-level, cross-platform RawEvent handling and then create another crate which provides an API for feeding notify::RawEvents into a state machine to interpret them and produce higher-level, "debounced" Events? Perhaps this could potentially ease the burden slightly for folks considering contributing or taking on maintainership? It might also make it a little easier to stabilize the cross-platform, lower-level parts of notify while deliberation continues on how to present a nice higher-level event API? Apologies if there's already an open issue for this that I have missed! Best wishes for your notify break :) @Dylan-DPC <https://github.com/Dylan-DPC> I like the idea of creating a dedicated organisation along the lines of notify-devs for managing notify. Perhaps this way it might make it easier for multiple folks to share the maintenance burden? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#209>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABGBC4HWOSE65PJESZUV6TQJMPXXANCNFSM4ISXMK7A> .

[Dylan-DPC-zz]

@Dylan-DPC I like the idea of creating a dedicated organisation along the lines of notify-devs for managing notify. Perhaps this way it might make it easier for multiple folks to share the maintenance burden?

yes that's the exact reason behind it

[ashleygwilliams]

hey folks! just to clarify- my package "notify forked" really only exists because we ran into a semver issue yesterday and are preparing a release of a project that uses notify. i dont really intend to do any feature work- just bug fixes so the project i do for work can continue to use notify for the time being. that being said, i am able to help with some things, triage, etc, so do let me know if i can help!

[mitchmindtree]

@passcod thanks for the detailed explanation!

@Dylan-DPC sounds great to me! Would you like to start the organisation? Then perhaps the initial maintainers could include yourself, @passcod (at least while they assist with the transfer), @ashleygwilliams, @0xpr03? I'd also be welling to help every now and then. Perhaps between all of us we can keep notify above water until someone more dedicated comes along and we can add them to the org as well?

[Dylan-DPC-zz]

@mitchmindtree yes will do when I get time later this week

[dhiemaz]

@passcod thanks for the detailed explanation!

@Dylan-DPC sounds great to me! Would you like to start the organisation? Then perhaps the initial maintainers could include yourself, @passcod (at least while they assist with the transfer), @ashleygwilliams, @0xpr03? I'd also be welling to help every now and then. Perhaps between all of us we can keep notify above water until someone more dedicated comes along and we can add them to the org as well?

I am willing to help also..

[JohnTitor]

@passcod @Dylan-DPC Hi, I'm interested in maintaining this crate.

[passcod]

As @Dylan-DPC said elsewhere, looks like this is resolved :)

[JohnTitor]

Can it be closed?

[dhiemaz]

If it resolved then can closed it..

[JohnTitor]

Okay, I'm going to close this, but feel free to re-open if this is still needed.

[Dylan-DPC-zz]

Yes it's resolved but it's not the end - in case anyone reading this in future would like to maintain this crate in future, just leave a comment here :)