On Fri, Dec 30, 2022 at 2:24 PM Tim Graham <timogra...@gmail.com> wrote: > As perfectionists, it's always hard to say (and hear) "no" when this sort of > request comes up.
I wrote a 2,000-word argument explaining why I believe this warrants backporting. I think that deserves more engagement than just a "no". > 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.) I strongly encourage you to read the linked forum post, where I have explained at length why I think it is serious enough to warrant an exception (and why I believe the policy should also be revisited/revised to accommodate cases like this explicitly). > 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. Reducing an opposing viewpoint to "it's hard to hear 'no'" probably falls into that category, too. And I will point out here, as I did in the forum thread, that the discussion here seemed to be blocked on a Merger who was not convinced and *who suggested the Steering Council as an option*. And procedurally, one point of the SC is to serve as a "court of appeal" if someone cannot convince the Mergers of the merits of a minor change. Meanwhile, I think Kevin is pointing in the direction of something important, which is that it is very easy to wind up in a vicious cycle where people get the impression that Django does not take its async story seriously and so they stay away from async Django, which then is used as an argument for not taking the async story as seriously (because obviously async Django is not that widely used), which then gives people the impression... Async is hard enough without Django making it harder still. So I think it is important for Django to make clear that the async story is supposed to be good and that the Django project is committed to supporting async. Right now, a developer who decides to try out async Django, with any currently-supported release, and follows the obvious "how to test my async code" clues in the documentation, will very likely end up with something broken. Worse: the breakage will be hard to diagnose, harder to find out the workaround for, and if they do manage to find it they'll likely also be treated to one or more threads of the Django project saying that due to the technicalities of when the breakage was first formally reported, none of the currently released and allegedly bugfix-supported versions of Django are actually eligible to receive a fix. I put it to you that this is not a good experience for the developer, that it is not the experience the Django project should be inflicting on the developer, that it will tend to erode the developer's trust and confidence in Django if this is the path Django decides to take, and that the solution to all this is comparatively easy: backport the frankly pretty minimal fix for the async test client into the full set of currently-supported feature releases of Django as a show of good faith and support, and to make async support easier for the community and the overall ecosystem. -- 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/CAL13Cg8NAXWw3nLm0TbJH68i8zzgsHGBySJW459KEW81tbY85g%40mail.gmail.com.
