dcell needs a new maintainer

tarcieri commented 9 years ago

I am not using dcell and have no plans on using dcell in the future.

I have been trying to review and accept patches, but things have not been going well. Being unable to quickly test changes against my own systems, it seems many of the ones I have accepted have caused breakages.

There are a lot of open issues lately: #69, #70, #73, #75, #77, #79, #81, #82, #85 and I don't have time to review or help fix them.

dcell could really use a new maintainer! Is anyone interested? @niamster? @TiagoCardoso1983?

niamster commented 9 years ago

Hi @tarcieri, I don't mind right now but I'm not a ruby expert so personally not sure if I can handle that. Though it's good opportunity for me to tune myself.

tarcieri commented 9 years ago

@niamster if you're an active user of dcell, you're honestly in a better position of me. I don't use it and can't spot regressions, which in the absence of a robust test suite (which dcell doesn't have) I can't properly evaluate changes

HoneyryderChuck commented 9 years ago

@tarcieri that sucks :/ I do understand you though, no use, no motivation for maintenance. That being said, I don't think you should be counted out for now though, since:

you have knowledge of celluloid internals like no one, and dcell is deeply integrated in it.
you have know-how about other actor frameworks that implement remote-actor communication like Akka and Erlang actors
you have an idea of what dcell should accomplish (at least in the ideal case).

In order for a stable "passing the torch" to succeed, in my eyes, one should establish short-term goals and medium term goals. I don't think a new maintainer should appear without us achieving compatibility with the latest celluloid version (0.16.0). All the rest could be achieved incrementally without needing as much input from you, thereby easining the transition phase.

So I would suggest establishing a roadmap (if it doesn't already exist one). From the top of my head:

Compatibility with 0.16.x Celluloid.
More better testing.
Actor address re-fetching.
Automatic Port selection
Actor Cluster Support

Tell me what you have in mind. And by the way, why not using dcell anymore? Not needing it for your use-cases or you found a better alternative?

digitalextremist commented 9 years ago

Reel seems to have a good informal model going, with an unspoken team of leading committers. Maybe in general Celluloid needs to formalize that approach and have two or more leading maintainers per suite-library a.k.a. "derivative" ... I'd volunteer to support a DCell maintainer team and step it up on supporting that, as with Reel. For example, I fell behind on the CurveZMQ support for DCell but @Asmod4n jumped on it and took initiative on pushing it forward substantially... if it were just me, or just him, the same thing you're experiencing would happen to us.

@halorgium seems devoted to Celluloid and Celluloid::IO alongside you, but maybe we can break up these derivatives into group maintenance.

I was recently approached by a publicly traded company to support their implementation of Reel and their deeper Celluoid::IO logic, and I could see many uses for DCell in that project, and I know there are other projects where enterprises could be using Reel and DCell now, if well maintained. I don't think we should hamstring any one person with maintaining a derivative, whereas I think having a BDFL for the underlying libraries will keep those internally consistent.

All this would just be a conversation in a ticket like this, per derivative, then updating README.md with specific maintainers who "agreed" to support the primary author(s). Enterprise implementations of Celluloid foundational pieces and derivatives will flourish with maintenance groups.

tarcieri commented 9 years ago

I appreciate you all bowing to my superior knowledge. I'm not trying to bow out of DCell. I am happy to consult as needed. However I feel someone who actually has hands-on knowledge would do a better job of triaging these issues.

Why am I not using dcell? Distributed systems are really hard, and I still don't think dcell is a good one. The very longstanding issues that people are complaining about are the exact same ones which keep me from using it.

How do we close the loop? Someone needs to do the work and make dcell more robust. I don't have time to work on it, sorry, and until someone does it won't be a useful system. Chicken and egg problem, and so forth...

Asmod4n commented 9 years ago

I belive most issues you mentioned in the initial post can be resolved by using https://github.com/zeromq/zyre for discovery. Zyre can be used for local and wide service discovery. Its in active use by http://theedg.es/

tarcieri commented 9 years ago

I created a "DCell Core" team and invited several of you to it.

Feel free to review and merge PRs amongst yourselves. I'll try to keep an eye on things.

niamster commented 9 years ago

@tarcieri thanks, it's an honor

digitalextremist commented 9 years ago

The team looks good to me.

I think we ought to follow the same pattern and also create a Reel team. Much of what I plan to do involves both, and moving toward more kinds of server classes.

Nice to 'meet' you @niamster

HoneyryderChuck commented 9 years ago

Thx for the invitation @tarcieri the "celluverse" has been helping me solve my concurrency issues, hope i'll be able to contribute back.

niamster commented 9 years ago

we can probably close this

celluloid / dcell

dcell needs a new maintainer #87