I'll say upfront that I haven't hit this particular issue, but it's mostly because I've avoided the Django async stack after some challenging experiences on the old(er) channels/daphne/etc. stack and its evolution. I've personally been in the "let's see how this develops" camp, which admittedly isn't the most community-focused. I'll resolve to do better in the new year.
This does sort of get at one aspect of this issue though - there's less usage of the async stuff as it's being rolled out slowly across multiple releases (which it itself an experiment of sorts), in part because [at least] some people don't trust it to actually be stable and are waiting to see the whole story before committing projects more fully. So from the perspective of "how many users are impacted", I agree the impact is probably low. But unless I'm misunderstanding the nature of the bug, this seems like it basically makes async views un-testable without a pretty annoying workaround (assuming it's more than a handful of views)? Plus the fact that it's not easily discoverable. FWIW (I'm an n of 1 obviously), but I go LTS-to-LTS for most projects, just given uncertainty in when I'll be upgrading any particular project, and wanting to be certain I never fall out of support for at least security releases. So for my own personal needs, fair enough - by the time I migrate my 3.2 projects to 4.2, this will be fixed, and it's unlikely that I'll personally be experimenting with async views in the next 3 months or so. But that doesn't really seem like the sort of behavior we want to encourage, if we're trying to actually get people to use async, get some real-world usage, and signal that Django has a good async story. I'm very cognizant of maintenance burden and feel sheepish advocating for someone else to do work, but if this thread is asking for opinions, I do think it's important to backport this issue. I can't literally equate it to a data loss bug (the specific example in the policy), but I'd argue that the gradual nature of the async rollout and its importance in moving Django forward mitigates for an exception to the backport policy. Cheers, Kevin On Friday, December 30, 2022 at 5:24:51 PM UTC-5 timog...@gmail.com wrote: > As perfectionists, it's always hard to say (and hear) "no" when this sort > of request comes up. I'm unconvinced it's a serious issue that requires a > break from normal policy. (Unreported for 2 years in 4 major releases; > simple workaround present.) > > Incidentally, escalating an issue to the steering council after less than > 24 hours (during a holiday week, no less) probably isn't something we want > to model as a best practice in forming consensus. > On Friday, December 30, 2022 at 12:48:47 PM UTC-5 James Bennett wrote: > >> I have put it to the Steering Council: >> >> >> https://forum.djangoproject.com/t/request-for-technical-board-steering-council-vote-requested-backport-ticket-34063/17920/1 >> > -- 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/f9fc0dad-fb09-4c5b-8c68-a83375f42d2en%40googlegroups.com.
