Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Looking for maintainers #209

Closed
passcod opened this issue Sep 1, 2019 · 18 comments

Comments

@passcod
Copy link
Member

commented Sep 1, 2019

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:

@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

This comment has been minimized.

Copy link
Member

commented Sep 1, 2019

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

@passcod

This comment has been minimized.

Copy link
Member Author

commented Sep 1, 2019

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

This comment has been minimized.

Copy link

commented Sep 2, 2019

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

This comment has been minimized.

Copy link
Member Author

commented Sep 8, 2019

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 #160. (done in #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

This comment has been minimized.

Copy link
Member Author

commented Sep 13, 2019

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

@mitchmindtree

This comment has been minimized.

Copy link
Contributor

commented Sep 13, 2019

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

This comment has been minimized.

Copy link
Member Author

commented Sep 13, 2019

@Dylan-DPC

This comment has been minimized.

Copy link
Member

commented Sep 13, 2019

@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

This comment has been minimized.

Copy link

commented Sep 13, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Sep 16, 2019

@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

This comment has been minimized.

Copy link
Member

commented Sep 16, 2019

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

@passcod passcod pinned this issue Sep 18, 2019
@dhiemaz

This comment has been minimized.

Copy link
Member

commented Sep 18, 2019

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

@memoryruins memoryruins referenced this issue Sep 21, 2019
4 of 6 tasks complete
@JohnTitor

This comment has been minimized.

Copy link
Member

commented Sep 30, 2019

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

@passcod

This comment has been minimized.

Copy link
Member Author

commented Oct 3, 2019

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

@0xpr03 0xpr03 unpinned this issue Oct 3, 2019
@JohnTitor

This comment has been minimized.

Copy link
Member

commented Oct 3, 2019

Can it be closed?

@dhiemaz

This comment has been minimized.

Copy link
Member

commented Oct 3, 2019

If it resolved then can closed it..

@JohnTitor

This comment has been minimized.

Copy link
Member

commented Oct 3, 2019

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

@JohnTitor JohnTitor closed this Oct 3, 2019
@Dylan-DPC

This comment has been minimized.

Copy link
Member

commented Oct 4, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.