Hi,
I'm against the backport for the same reasons already mentioned by
Carlton. So -1 from me.
Best,
Mariusz
--
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
On Sun, Jan 1, 2023 at 7:01 PM Tim Graham wrote:
> Incidentally, I don't think it's important for the ultimate decision here,
> but I looked at the below analysis of ticket #32189. Carlton's analysis on
> the ticket that request.POST is empty when using 'content-type':
> 'application/json'
Incidentally, I don't think it's important for the ultimate decision here,
but I looked at the below analysis of ticket #32189. Carlton's analysis on
the ticket that request.POST is empty when using 'content-type':
'application/json' remains true. The results of the tests provided in the
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
On Sun, Jan 1, 2023 at 12:54 PM Tim Graham 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
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
Hi,
I think at this point it would help to move the discussion forward, if
we tried to step beyond the specific issue and phrase the revision in
the backporting policy. This will let us, I hope, have a more
principle-based discussion.
If I get it right -- please correct me, James -- it would be
On Behalf Of James Bennett
Sent: Saturday, December 31, 2022 5:18 PM
To: django-developers@googlegroups.com
Subject: Re: Backport for ticket 34063?
On Sat, Dec 31, 2022 at 2:12 AM 'Adam Johnson' via Django developers
(Contributions to Django itself)
wrote:
> In the past I have also b
On Sat, Dec 31, 2022 at 2:12 AM 'Adam Johnson' via Django developers
(Contributions to Django itself)
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
erent ways to self-backport
the fix: https://github.com/adamchainz/django-ticket-34063-backport (client
only, not request factory). The code for those three techniques follows. I
hope you can use one of these, James.
*1. Monkey-patching*
import django
from django import test
if django.VERSI
On Fri, Dec 30, 2022 at 11:22 PM Carlton Gibson
wrote:
> Under normal circumstances you just use the sync Client, as you've always
> done. `response = client.get(`/my-async-view/`)`.
> Django handles that the **view** is async for you.
>
> It's only if you need to write an actual **async test**,
ng 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-steeri
On Fri, Dec 30, 2022 at 2:24 PM Tim Graham 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
bably 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-technic
:
>
>
> 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 t
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 i
> Even if it will not be fixed for older versions, Django 4.1 ought to be
eligible for a backport.
What you're suggesting is a change to the backport policy. That may be the
right thing to do, but it would be quite a significant change.
These issues — where a bug report/fix comes outside the
On Fri, Dec 30, 2022 at 2:04 AM Carlton Gibson
wrote:
> No it's not. It's a bug in AsyncClient and AsyncRequestFactory, that means
> if you're using those on older versions of Django, you'll need to work
> around.
> This is no different than any of a thousand other cases where there's been
> a
James,
I think the backport policy has proven itself over the years, no?
"Django lied" — that's a bit melodramatic don't you think?.
Django introduced a new feature, as it is wont to do.
There was a bug in that new feature, as there are wont to be.
Unfortunately that bug was not discovered
On Fri, Dec 30, 2022 at 1:27 AM Carlton Gibson 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
OK, yes, that's probably right.
Had #34063 been reported during the 3.1 cycle it would have been a release
blocker.
As it was, it wasn't reported until 4.0 (when main was already 4.1) so two
cycles later.
As such it no longer qualifies for a backport.
It's frustrating when this happens, but the
On Fri, Dec 30, 2022 at 1:09 AM Carlton Gibson wrote:
> All you're talking about is adding this to your test cases right?
>
> # Work around Django #34063 until 4.2.
> request.body
As far as I can tell it needs to go in whatever code will *read*
request.POST, not the code that generates the
James,
All you're talking about is adding this to your test cases right?
# Work around Django #34063 until 4.2.
request.body
# ... continue
C.
On Fri, 30 Dec 2022 at 10:04, James Bennett wrote:
> On Fri, Dec 30, 2022 at 12:01 AM Carlton Gibson
> wrote:
> > When I looked at the trace you
On Fri, Dec 30, 2022 at 12:01 AM Carlton Gibson
wrote:
> When I looked at the trace you posted in IRC yesterday, my first thought was
> "3.2?". I think supporting Django 3.2 at this point isn't worth the effort.
It's also broken in 4.0 and 4.1. I just posted the first trace I got
back from my
Hey James.
Grrr.
I don't think this justifies an exception to the backport policy. It's not
significantly different from any of any number of other fixes that folks
ask for a backport for and we say no. Fielding "but you backported that
one" isn't an extra task that's going to be helpful.
https://code.djangoproject.com/ticket/34063
The short summary of that ticket is that there was a significant
behavioral difference between django.test.Client and
django.test.AsyncClient: with AsyncClient, any view or middleware
which attempted to access request.POST without first accessing
26 matches
Mail list logo
