On Sat, Dec 31, 2022 at 2:12 AM 'Adam Johnson' via Django developers (Contributions to Django itself) <django-developers@googlegroups.com> wrote: > In the past I have also been frustrated at particular bug fixes not being > backported. But I've gradually come to appreciate just how valuable the > backport policy is. It keeps Django forward-facing, and prevents the fellows > spending much of their precious time backporting.
In the forum post, which attempted to be a single-place-to-read summary of the argument, I pointed out the benefits of the backport policy, and also pointed out that making exceptions to it from time to time has happened and without ill effect. I also explained why I believe *not* backporting this runs counter to the goals the backport policy is theoretically supposed to achieve, and why an exception to backport this fix is correct. As I said above: > So I ask that people actually read and engage with that in future replies. > This is the > bare minimum of respect and good faith that can be expected of participants in > discussions on this and other forums concerning Django and its development. I should not have to be asking people to show that basic level of respect and good faith. Yet here I am having to ask more than once. > Also, I’ve learned several techniques to backport within projects when > required (e.g. > https://adamj.eu/tech/2020/07/29/backporting-a-django-orm-feature-with-database-instrumentation/ > ). I encourage others to do the same. We could perhaps document some of > these techniques (one source: Paul Ganssle’s talk ”What to Do When the Bug is > in Someone Else’s Code ”: https://ganssle.io/talks/#upstream-bugs ). > > I also believe that there is no overriding reason to backport in this case. > Self-backporting the fix within a project is very feasible—there’s no need > for "the request.body workaround" (which is an understandable source of > frustration). This has multiple issues. First, merely from a technical perspective, a "self backport" for this bug can never be as self-contained as you seem to think it would be. Take, for example, the code I was writing when I tripped over the bug: a middleware that accesses request.POST, and is part of an application I distribute to others. Even if I "self backport" a working AsyncClient into my own test suite, anyone who has my middleware configured in their settings now has the bug, too, and now *their* test suite must account for it. And then anyone who uses that person's code gets "infected" by it and now has to account for it. This leads to either: 1. Everyone must maintain their own copy of the "self backport" of things Django shipped, or 2. Everyone relies on a centralized repository for the code. The first case clearly is bad: it takes not many individual developers at all needing to maintain their own "self backports" before the total maintenance cost imposed on the community outweighs the maintenance cost Django would have incurred by just applying the fix. And given that this is a high-severity bug in a key part of a feature Django wants to hype up, I think the current status quo of "not many affected" will not last long. And the cost analysis here, it should be noted, does *not* include the decreased trust and confidence in Django on the part of developers who see such a high-severity bug that Django knows about and actively refuses to apply a fix for, even when *all* currently-released versions of Django are affected by it. The second case is worse: the correct name for a centralized repository of Django with bugfixes applied is... Django. If we reach the point where people in the community are expected to maintain forks just to get documented basic functionality like the unit-testing tools working, we are in a truly bad place indeed. Finally, this ignores the question I have asked several times now: if the official recommendation of the Django project is for everyone in the Django ecosystem to apply workarounds or "self backports" for this bug, how exactly is that to be communicated? It cannot go into the documentation of the affected Django versions, because the same strict "computer says no" reading of Django's policies that is being wielded against the idea of a backported bugfix also applies to backporting such notes into the documentation of older releases. Which leaves this in a state of undiscoverability -- as I noted, I am someone who is not exactly a novice at tracking down problems in Django, and it took me over a day of working on this to end up at ticket 34063. And if an exception *is* to be made to backport a "how to fix it yourself" into the documentation of older versions, roughly the same amount of effort would suffice simply to backport the bugfix itself. Even better: backporting the fix does not create a stream of people reading the Django documentation, discovering "wait, there was a bug of this severity and their solution to it is to tell me to fix it myself", and having that affect their perception of Django's commitment to reliability and stability. Which brings me back to the point I have been making over and over: this bug is worth an exception to the backport policy, should be backported to the full suite of currently-supported releases (4.1, 4.0, 3.2), and the backport policy itself should be revisited so that severe bugs like this can't slip through a "well technically the policy does not allow...". (after which there should also be a post-mortem on how Django ended up shipping AsyncClient in such a broken state in the first place, but one thing at a time) -- 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-BkHR0L6QtJwdWfpb80vD0e-bHNKVo_oBs%2B9yLmpseEw%40mail.gmail.com.
