Re: Consider making asgi_rabbitmq an official Django project.

I agree that making a separate technical team for channels will help organization process. I think that moving Daphne and asgiref will result in a really bad situation. Probably we will end up with unmaintained ASGI infrastructure. So Channels won't work either because the underlying layer of

Re: Consider making asgi_rabbitmq an official Django project.

The other channels projects are currently maintained by me and me alone (some people were initially helping but have since got busy with other things), which is an untenable position and one I am trying to seek help to fix but have not succeeded so far in doing so. This is one of the reasons I

Re: Admin browser support policy

Django 1.11 dropped support for IE8 and below as those browsers are end of life. It looks like we could now drop support for IE<11 based on this from Microsoft: "Beginning January 12, 2016, only the most current version of Internet Explorer available for a supported operating system will

Re: Consider making asgi_rabbitmq an official Django project.

>From my perspective, there's been little visibility into how things are going with the other channels related official projects. Who are the other maintainers there? I would present this question to those people (hopefully there are some others by now?) rather than to the Django maintainers

Re: Default to BigAutoField

On Friday 09 June 2017 15:59:50 Kenneth Reitz wrote: > However, it should also be noted that those same larger applications > are the ones that are likely to run into this problem eventually, so > perhaps forcing the migration is the best path moving forward. Existing models are the problem.

Re: On ASGI...

> I note that your examples do not include "receiving messages from a WebSocket and sending replies" - I would love to see how you propose to tackle this given your current API, and I think it's the missing piece of what I understand. I've just added an `echo` WebSocket example. I've also now

Re: Vendoring Select2

To learn about some history of noConflict, I'd use this Google search: jquery noConflict site:code.djangoproject.com The first two results are some tickets with discussion: https://code.djangoproject.com/ticket/12882 - jQuery.noConflict() in admin breaks site specific code with jQuery

Follow-up to #28307: Possible app_template improvements

Hello everyone, I'm a Django user for some years now, and I find myself tweaking the app structure after `./manage.py startapp foo`. I try to modularize the code and keep things separated. For example I don't like form classes in `views.py`, or very long `tests.py` files (and after also the

Admin browser support policy

This topic seems to appear frequently over the years, but I've yet to see a clear decision. Without a clear Browser Support Policy for admin, it can be very unclear what cleanups, optimisations, and improvements can be made. Collin Anderson suggested supporting IE11+ ("as that's the latest

Re: Admin browser support policy

I certainly care about mobile support. Being able to use even a limited version of Django admin on my phone would make my life significantly better. PJJ http://philipjohnjames.com On Wed, Jun 14, 2017 at 4:02 PM, Curtis Maloney wrote: > This topic seems to appear