Potential suspension of Channels development

[Andrew Godwin]

Hi all,

I'm writing to you all to update you on the current situation of Channels and related libraries (channels-redis and Daphne) and potentially ask for help.

I've been the sole maintainer of these projects for quite a while and it has become unsustainable - all of my energy is taken up fielding issues and support requests and I haven't been able to even get myself to start looking at Django async stuff because of it.

Given that, if nobody else can step forward to take over, I'll have to put those three projects (Channels, channels-redis, and Daphne) into an explicit maintenance mode where they only accept security requests via the normal security@ route, and start the process of retiring them as active Django projects, as I don't want to give the impression they're still maintained if they're not.

(note: the asgiref project is still fine and should probably move out of Django to its own effort at some point giving the growing set of ASGI tools)

If people are willing to take over maintenance, I'm happy to help explain some things but I don't have the bandwidth to bring someone completely up from scratch, so I can't help mentor someone who is totally new to maintaining open-source Python (sorry!).

Once I recover a bit from the burnout I'll be able to come back and help with the really complex bugs; the main thing I need out of is the seemingly endless support requests and weird WebSocket client bugs.

My personal deadline for this is two weeks, on February 1st. If you want to help out, please feel free to reply either here or get in touch with me personally to chat about what's involved.

Andrew

[Nasir Hussain]

Hi andrew, I can help in maintaining the projects. Kindly let me know what are the next steps.

Thanks

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFwN1uonedcUeLz8zD%2BK5Ma82gLyAX8g0s58HeT%3Dq-dMgcLxfw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Andrew Godwin]

Hi Nasir,

I'm looking for help from people with a strong history of open source maintenance and Django/Python/async contributions, since I can't really guide people through it and I need to be able to trust those who I give access to. If you think you meet that, email me personally and I'll outline what's needed.

Andrew

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAB5Hk3yC0MnbJwh%2BMQ63%2BdXha9pnBo6zL_kp2n5wNd8oqkT1UQ%40mail.gmail.com.

[sibasish mohanty]

Hi ,

I also can help in maintaining the projects.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAB5Hk3yC0MnbJwh%2BMQ63%2BdXha9pnBo6zL_kp2n5wNd8oqkT1UQ%40mail.gmail.com.

[Michael Martinez]

Hi Andrew, 

We have a pretty active Django channel in our Slack group if you would like to direct all support requests there in the meantime. Many of us including myself are using Django Channels in production can help with basic support questions.

Take care of yourself and thanks for everything you've already done!

https://pyslackers.com/

[Dipankar]

Hi, I am also interested to contribute on this topic. Please guide.

--

You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFwN1uonedcUeLz8zD%2BK5Ma82gLyAX8g0s58HeT%3Dq-dMgcLxfw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

Warm Regards,
Dipankar B.

[Carlton Gibson]

Hey Andrew. 

I've been thinking a lot about this. You clearly shouldn't be maintaining Channels single-handedly indefinitely. 

On Thursday, 17 January 2019 19:07:06 UTC+1, Andrew Godwin wrote:

Given that, if nobody else can step forward to take over, I'll have to put those three projects (Channels, channels-redis, and Daphne) into an explicit maintenance mode where they only accept security requests via the normal security@ route, and start the process of retiring them as active Django projects, as I don't want to give the impression they're still maintained if they're not.

(note: the asgiref project is still fine and should probably move out of Django to its own effort at some point giving the growing set of ASGI tools)

 

I know Channels started out separately, but, it's time to think about what, if anything of channels, is to be brought into core, or become THE WAY we do things or... Yes, we need more hands, but there's a bunch of people who can help out, and at least part of the problem is your out there in the wings by yourself (with not much visibility.) 

Q: How does Channels fit into the "Django Async Roadmap"? 

To the extent that it does, I think there's a case for asking the board and the DSF more widely to throw everything we've got behind making sure it's properly resourced. 

Once I recover a bit from the burnout I'll be able to come back and help with the really complex bugs; the main thing I need out of is the seemingly endless support requests and weird WebSocket client bugs.

I presume you DON'T offer support on the issue tracker, and point people to other channels? I'd be happy to "straight-bat" obvious tickets away. (Michael's offer to recieve is valuable there.) 

"...and weird WebSocket client bugs."

Can I ask you to explain what you mean there? (Point to a ticket maybe.) What kind of query do you get? Is there a particular knack to working out if it's a valid bug or not? (Or is it apparent?)

Thanks for all you work here. Legend. 🙂 

Kind Regards,

Carlton

[Shrawan Poudel]

Hello, i am interested in helping in this project. Please guide thought the process for helping . 

I have been using these projects in many of my Production app .

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/68626427-d97d-4053-8836-5382483f63af%40googlegroups.com.

[Andrew Godwin]

On Sat, Jan 19, 2019 at 12:13 PM Carlton Gibson <carlton...@gmail.com> wrote:

Hey Andrew. 

I've been thinking a lot about this. You clearly shouldn't be maintaining Channels single-handedly indefinitely. 

 

I know Channels started out separately, but, it's time to think about what, if anything of channels, is to be brought into core, or become THE WAY we do things or... Yes, we need more hands, but there's a bunch of people who can help out, and at least part of the problem is your out there in the wings by yourself (with not much visibility.) 

Q: How does Channels fit into the "Django Async Roadmap"? 

To the extent that it does, I think there's a case for asking the board and the DSF more widely to throw everything we've got behind making sure it's properly resourced. 

The main problem with Channels, I feel, is that is solves the wrong problem - it's focused on WebSockets, which is a niche feature that a few people are happy we provide but most people have no practical use for.

Instead, I think Django should focus on a good async path for HTTP - views, ORM, templates, and the like. This is what I want to get done if I can get my time and energy back!

I presume you DON'T offer support on the issue tracker, and point people to other channels? I'd be happy to "straight-bat" obvious tickets away. (Michael's offer to recieve is valuable there.) 

I do try to do this - I wrote a standard page last year to help out with batting away (https://channels.readthedocs.io/en/latest/support.html) - but sometimes it's hard to triage the bug from the support request. Your help there would be most appreciated, and yes, I should add Michael's offer to that support page.

 

"...and weird WebSocket client bugs."

Can I ask you to explain what you mean there? (Point to a ticket maybe.) What kind of query do you get? Is there a particular knack to working out if it's a valid bug or not? (Or is it apparent?)

I don't want to single anyone out, as it's not their fault, but bugs like this: https://github.com/django/daphne/issues/244

This person did the work and figured it out for the most part, but lots of bugs that complex and confusing come in with just the first part of the issue and I'm left wondering if it's their browser, their server, their Python install or actually Channels.

At some point, I wake up every morning to 5-6 emails from the various projects and it overwhelms, as I'm sure you've encountered. Even the bugs are nasty enough that I don't feel like fixing them once I've figured out they're actually bugs.

 

Thanks for all you work here. Legend. 🙂 

And thank you for your response and help :)

Andrew 

[Guilhem Saurel]

Hi Andrew,

Have you considered Jazzband (https://jazzband.co/) for this ?

Guilhem.

[Michael Martinez]

Hi Andrew

RE:

 

 I feel, is that is solves the wrong problem - it's focused on WebSockets, which is a niche feature that a few people are happy we provide but most people have no practical use for.

To me, Websockets is the defining use case for using Django Channels. From a user POV, saying that Channels is focused on the wrong problem (websockets) is like saying Django is too focused on HTTP.

When I have selected Channels (vs other tools), my rationale was not:

"I need a general purpose async platform and it would be great if it worked with Websockets, ZeromQ and played nice with Django..." (therefore Django Channels vs Tornado vs ...)

rather my rationale is more like: 

"I need to build real time features with Websockets using Django.." (therefore Django Channels).

[Andrew Godwin]

On Mon, Jan 21, 2019 at 4:34 AM Michael Martinez <writemicha...@gmail.com> wrote:

Hi Andrew

To me, Websockets is the defining use case for using Django Channels. From a user POV, saying that Channels is focused on the wrong problem (websockets) is like saying Django is too focused on HTTP.

When I have selected Channels (vs other tools), my rationale was not:

"I need a general purpose async platform and it would be great if it worked with Websockets, ZeromQ and played nice with Django..." (therefore Django Channels vs Tornado vs ...)

rather my rationale is more like: 

"I need to build real time features with Websockets using Django.." (therefore Django Channels).

 

Oh, I totally get that, and Channels does well at providing WebSockets - the problem is that it's still an area with a lot less interest and also one I personally have no use for at the moment. Those things combined mean that WebSockets is not something I'm really interested in supporting for free right now; I'd have to be paid to work on it (as I was with the Mozilla grant for a lot of Channels' development).

Andrew 

[John Obelenus]

Chiming in. As a long-time django user (nearly a decade), websockets is an area that the project on the whole is very, very, far behind the leading edge of the web industry. It's great, often desirable, to not be *on* the leading edge, but in my opinion, the project is too far behind it.

There are numerous projects where I would, now, not consider using django (or at least, using it only for the admin to save time/effort). That is the first issue that I see for the django project as a whole.

Secondly, and probably something Andrew expects to be helped (if not outright solved), is the general speed of serving requests. Async can absolutely help here (How much it helps is up for debate). As a developer who is using a lot more NodeJS now the inherent speed in that platform's request lifecycle can often be a game-changer in terms of performance and resources needed.

[Christian González]

Hi,

I'm no experienced developer nor a Django contributor, but I "suffered" from this theme too. What I tried in the past is to create a Django "application", or more a framework (https://pypi.org/project/gdaps/), to support "plugins" which consist of a backend (the django part), and an included frontend (which shoud contain a "plugin" of a Js-framework like Vue.js or Angular, etc) that "blends" in into the web client dynamically.

I have experimented with using templates serving Vue code, or separating the part that is served to the browser from the Django backend in a different directory, bypassing Django templates, and did not succeed much.

This all is not directly related to the theme here, but where it is connected, is that, for writing a modern application nowadays, you IMHO have to be responsive in the frontend, and I think that async calls are not smart enough to solve that.

If you ever tried the "easiness" of Meteor, you always envy that when using Django with templates.

So: If I had a wish to Santa Claus :-), I would really support Django having "Channels" (or however it may be named) included more deeply into the system: I think that the Templates approach is not the worst, because it is very flexible. It just doesn't have a solution to the communication problem between server and client. Again, if I could wish something, It would be Integration of frontend frameworks into the template language and having calls to e.g. DRF included INTO the template language, like the "batteries included" approach of Meteor with their "connected" variables that update automatically when another client changes them.

This all is possible with Django DRF, channels and a modern Js framework, but VERY much boilerplate code and hand-written updates, no-way modern.

I know it's much I demand here - I just want to add my 2cents - Django is GREAT software.

It's just that the frontend side (templates, auto-communication and data bindings) did not gain that much love as the backend.

Maybe you'll say "Hey, Django IS only a backend". Yes and no. If so, you can remove the templates completely. It's not a backend, it just focussed on the backend more than on the frontend.

If there would be a way to integrate channels more deeply into Django, together with frontend 2-way data bindings, push notifications etc., I would really appreciate it and could imagine supporting that using money too.

Cheers,

Christian

Am 22.01.19 um 15:18 schrieb John Obelenus:

--

You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b357add7-cd44-4c12-b29b-0d28150417a2%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

-- 
Dr. Christian González
https://www.nerdocs.at
+43 650 7644477

[Andrew Godwin]

Just to update on this - nobody has individually come forward to help full-time, though I have seen Carlton help out on a few issues (thanks for that).

I've added the PySlackers group into the support docs, as well - thanks for that offer.

I'm still planning to remove myself from watching all the repos come Feb 1st, and barring positive confirmation someone else is going to actively take over I'll put up notices on all the projects that they are actively unmaintained apart from security issues.

Andrew

[Jamesie Pic]

On Sun, Jan 20, 2019 at 3:19 PM Shrawan Poudel <shr...@gmail.com> wrote:
>
> Hello, i am interested in helping in this project. Please guide thought the process for helping .
> I have been using these projects in many of my Production app .

Watch the repository on github, read the pull requests and ask
questions about submitted code where you feel that it could be
improved.

Look at the issues, try to reproduce them, submit a pull request with a fix.

On Mon, Jan 21, 2019 at 12:27 AM Andrew Godwin <and...@aeracode.org> wrote:
>
> Instead, I think Django should focus on a good async path for HTTP - views, ORM, templates, and the like. This is what I want to get done if I can get my time and energy back!

There's nothing I wouldn't do to see that happening !

--
∞

[Asif Saif Uddin]

Hi Andrew!! I would love to help as a co-maintainer of the projects related to django-channels. my github: auvipy

[Andrew Godwin]

OK, another update on the update (sorry, I am using the last of my energy to arrange this handover, so I missed some things yesterday)

I'm going to hand over to a team of Carlton, Jamesie and Asif for now - I'll get the docs on the repo sorted out tonight and make write up a few more docs on how to run the release side of things.

I'll give Carlton admin access to the repo if he doesn't have it already, and the two of you I'll grant commit access. Hopefully that should be enough to give this a solid go. I'll leave notifications for @andrewgodwin on, on github, for now, so if you really need me try that, but I may turn that off if it turns out to be too much.

Thanks all who came forward. I'm hopeful that things can be kept going!

Andrew

[Carlton Gibson]

Hey Andrew. 

Thanks to Jamesie and Asif for volunteering to help. 

Some general point, I'll make publicly, because they're general purpose: 

• Due to Andrew's great work, the repos are in a good condition. Very few open issues. The main task is to keep it that way: triaging the new tickets, closing those we can. 
• Let's use the labelling system Andrew already has in place. (No issues if we don't do that perfectly, but lets try.) 
• I don't think we can keep offering support in the repo. We need to guide people to support channels. (A little hint is OK if you've got one immediately.)
• I'll set up protected branch rules, so all changes via PR (with approvals) so we make sure we're on the same page, and can continue Andrew's high standards. 
• Let's not ping Andrew until we've explored all other possibilities. Burnout/overwhelm is rubbish and self-care is the #1 priority. 

Thanks for all your work here Andrew. Have a breather. We'll try and keep it going. 🙂

(I'm sure there's other people here who can help us when we get stuck...) 

Kind Regards,

Carlton