On Fri, Dec 30, 2022 at 1:27 AM Carlton Gibson <carlton.gib...@gmail.com> wrote: > It's frustrating when this happens, but the backport policy has proven its > worth time and again. > I **really** don't see the case for making an exception here. > (The policy has more value than the inconvenience in any of these cases, or > even all of them summed.)
I don't see the value here. If it's left as-is, the message is, effectively, that Django lied about its async support for years, but suddenly *now* is asking people to trust the claims of async support. Unless another major bug gets found, in which case "well, *now* you can trust Django on async" will get kicked down the road again. This is a showstopper of a bug, and just leaving it deliberately unfixed in *every released version of Django* because "policy said no" has the potential to do a lot of damage to Django's reputation. > Adding the support here is difficult and slow enough. Backporting fixes to > discovered bugs, outside the established policy, is making an unrealistic > burden for ourselves. I'm not saying every bug found with async needs a backport. But one that literally prevents the built-in testing tool from working with a huge swathe of views and middlewares (including potentially some built in to Django itself), *when that tool is documented and Django claims to officially support it*, is just unacceptable. I'll work up the patches myself if that's what it takes. -- 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-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAL13Cg-tMbTXN3WwqjqjgiLj1rrMO6K8YhRHnci6Qzw2d52Y-w%40mail.gmail.com.