I guess it's nice to have a strict backport policy, partly to avoid hours of discussion like this, which ultimately boils down to a judgment/prediction about severity and whether or not the current backport policy should be amended. If I encountered a similar issue, I would have just worked around it and moved on. Surely there are other issues like this one that don't meet the current backport criteria but that could be similarly argued by someone persistent enough. It would be nice if the outcome here avoided that in the future.
I guess there's not much to add on either side of the argument at this point. Perhaps the best solution is what Shai outlined: to propose amending the backport criteria, either by expanding the LTS backport categories beyond security and data loss issues, or by allowing the steering council to vote on backport proposals on a case-by-case basis, at least if there's no consensus on the mailing list. On Sunday, January 1, 2023 at 5:41:03 PM UTC-5 James Bennett wrote: > On Sun, Jan 1, 2023 at 12:54 PM Tim Graham <timog...@gmail.com> wrote: > > Older Django releases are currently maintained with minimal support that > allows existing projects to continue running securely. I don't think we > should invest resources in promoting them as a place to use experimental > features. A benefit of running an old LTS release like 3.2 is that any > release at this point is probably a very important upgrade (security or > data loss issue). If we start making new LTS bug fix releases to fix > experimental features, releases may be more frequent and less important. Of > course, with more changes, the risk of unrelated regressions increases, > including the possible bad situation in which users put off a bug fix > upgrade because it doesn't have any security fixes only to face issues > updating to a subsequent security release because of an issue in an interim > bug fix release. (Maybe mergers can estimate how many other async fixes > would be eligible for a backport based on the proposed criteria.) > > The backport policy already says that Django will backport certain > things into older releases. I do not agree with your assessment of the > risk of backporting, but even if we grant it for sake of argument, the > Django project overall has already clearly endorsed -- through the > current backport policy -- the idea that some fixes are important > enough to override such concerns and to backport even into releases > that are on "minimal" support. > > I happen to think that this is one such fix, for reasons that I have > laid out at length. I also think the backport policy should be amended > to prevent an issue like this from "slipping through the cracks" again > in the future. I am still considering the wording Shai proposed, > though on first read I thought it was getting at the right idea. > > > James argues that this bug that went unreported for 2+ years is now very > important and is going to cause massive pain for many users. Only time will > answer this, but I'm skeptical. So far I believe we've seen two people > affected, James and the ticket reporter. > > Well. > > I had been trying to avoid bringing this up because I felt that the > backport policy and the severity of the bug were the things to focus > on, and because I was trying to avoid singling out individual mistakes > that contributed to the situation we have now. But there is at least > one other report of this bug in the Django Trac instance. It is the > first one I found when trying to diagnose the problem in my own code > (and the one I mentioned in my initial question on IRC, as anyone who > saw that can confirm), and it is one that was filed only a couple of > months after the release of Django 3.1, so well within the window of > time when the backport policy would have said to apply the fix to the > 3.1 branch as well as to main. It also correctly diagnosed the source > of the bug and provided an attempt at a patch. > > That ticket was #32189: > > https://code.djangoproject.com/ticket/32189 > > But it was closed invalid as a user error. We can debate whether the > user should have been trying to access request.POST for their > particular use case, but we cannot debate whether this is the > underlying bug that user was encountering. It also was clearly not the > normal behavior one ought to see from accessing request.POST, even in > a non-POST request or supposedly non-appropriate context, and likely > either should not have been closed, or should have produced a > follow-up ticket to investigate why that specific behavior was > occurring. > > As for whether anyone else is affected: my searching turned up several > references on other sites to the exact error message the bug produces, > which all seemed to receive replies along the lines of #32189: that it > was the fault of the reporter for accessing request.POST rather than > request.body. > > So. I have said several times that using a strict reading of the > backport policy to avoid fixing a severe bug sends a bad message. I > will amend that now, and say that using a strict reading of the > backport policy to avoid fixing a bug, when the bug was reported to > Django within a window where the backport policy should not have > mattered, sends an even worse message. > > I also do think that more people will trip over this bug as they start > using async Django, and that leaving it unfixed creates a problem of > how to communicate the need for a workaround without violating a > strict reading of the backport policy. > > > This bug will be a non-issue for third-party apps with the release of > Django 5.0 in December if they follow the suggested Django version support > policy: > > I have repeatedly pointed out that I do not think Django should force > the choice of long-delayed async adoption, or fracturing of the > community, onto maintainers of third-party packages and libraries. My > objection was to waiting until Django 3.2 drops out of support, which > is in April 2024, but the objection would apply equally to saying that > a feature released in 2020 must be left in a state where it is not > reliably usable until December 2023. > > > Until then, apps could run the affected tests only on Django 4.2 (which > will have an alpha release in about two weeks) if they don't want to work > around the bug. > > I still maintain that this is extremely poor developer experience, and > sends an extremely bad message about Django and its commitment to > reliability and stability. At the moment, there are zero > officially-supported releases of Django one can install that have a > working AsyncClient, despite AsyncClient being a documented and > allegedly supported API since August of 2020. Under my proposal, > developers would not have to wait for a future feature release just to > have the first actually-working AsyncClient, and developers of > third-party packages and libraries would not have to resort to > workaround, or delay async adoption, or fracture their usual support > matrices to deal with the bug. > > So I return again to my contention that an exception ought to be made > to the backport policy, and that the fix should be backported to all > currently-supported Django release series: 4.1, 4.0, and 3.2 LTS. > -- 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/1df5a798-5000-46a4-9886-b6cf15ce95b3n%40googlegroups.com.
