Re: status of 1.10 release blockers

[Claude Paroz]

Le vendredi 17 juin 2016 16:52:50 UTC+2, Tim Graham a écrit :
>
> There are a few small issues to finish up, but if all goes well, the beta 
> release will happen sometime tomorrow (at least 24 hours from now).
>

I'm a bit worried about https://code.djangoproject.com/ticket/26719 which 
could have security implications for 1.10. To be investigated...

Claude

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1ba746a8-f420-4230-be18-4ec45504adfc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: status of 1.10 release blockers

[Tim Graham]

There are a few small issues to finish up, but if all goes well, the beta 
release will happen sometime tomorrow (at least 24 hours from now).

On Thursday, May 19, 2016 at 2:08:59 PM UTC-4, Tim Graham wrote:
>
> The CSRF patch is merged. I'm a bit stuck on the middleware one, however, 
> I don't think it's a blocker for alpha. I think I'll create the stable 
> branch and make the release later today (in about 7 hours), unless there 
> are objections.
>
> On Wednesday, May 18, 2016 at 10:03:17 PM UTC-4, Tim Graham wrote:
>>
>> A couple issues remain before the alpha release:
>>
>> Issue: Fixing some new-style SessionMiddleware to process the response 
>> even if the view raises an exception.
>> Status: This is somewhat in design decision needed if anyone would like 
>> to take a look and offer feedback. I'll look at it more closely tomorrow.
>> https://github.com/django/django/pull/6618
>>
>> Issue: Made CSRF tokens change every request.
>> Status: Awaiting final (trivial, I believe) updates from Shai.
>> https://github.com/django/django/pull/5605
>>
>> Issue: i18n test failures on Windows
>> Status: Awaiting someone with interest in Windows i18n to investigate. 
>> I'm not considering this a blocker for the release (alpha or otherwise) 
>> since we can't guarantee sometime with Windows expertise to fix the issue.
>> https://code.djangoproject.com/ticket/25677
>>
>> I hope to resolve these issues and make the alpha release tomorrow or 
>> Friday.
>>
>> On Saturday, May 14, 2016 at 7:40:32 PM UTC-4, Tim Graham wrote:
>>>
>>> Time to kickoff the progress tracker for the next major release!
>>>
>>> At this time, I'm considering master feature frozen besides the tickets 
>>> marked "ready for checkin" [1] and those tagged "1.10" [2]. Let me know if 
>>> I missed anything critical.
>>>
>>> I'll continue working with the ticket owners to polish those patches. 
>>> I'll also continue merging bug fixes until we create the stable/1.10 branch 
>>> and issue the alpha release, which I'd like to do sometime next week.
>>>
>>> [1] 
>>> https://code.djangoproject.com/query?status=assigned=new=Ready+for+checkin=id=summary=status=owner=type=version=priority
>>> [2] 
>>> https://code.djangoproject.com/query?status=assigned=new=~1.10=Accepted=id=summary=status=owner=type=version=changetime=1=changetime
>>>
>>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fe6a92c8-d4ca-41b5-8169-990d0f79dc14%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Would a patch to add allow_empty_strings=True to CharField be accepted?

[Jon Dufresne]

Would recent commit solve the problem for you:
https://github.com/django/django/commit/267dc4a2882182f71a7f285a06b1d4b15af0

Relevant ticket: https://code.djangoproject.com/ticket/4136

On Fri, Jun 17, 2016 at 3:27 AM, Luke Benstead  wrote:

> Hi!
>
> We've recently hit upon a problem where we need empty strings in a
> CharField to be coerced to NULL. Obviously nullable CharField's are frowned
> upon but we have the requirement that non-empty values must be unique, so
> the empty state must be NULL.
>
> We've written a custom subclass of CharField to deal with this, but when I
> found the bug report[1] for this issue, the wontfix justification was that
> it would make things backwards incompatible. What I'm proposing instead is
> we add another option to CharField's __init__ which defaults to true called
> "allow_empty_strings". If set to False, and the field is nullable, this
> would coerce empty values to None. If the field was not nullable, this
> would raise an exception (ValueError?, IntegrityError?).
>
> Is this an acceptable solution to support this use-case?
>
> Thanks,
>
> Luke.
>
> [1] https://code.djangoproject.com/ticket/9590
>
> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/ad3d155c-6386-4d4f-a4f3-07544c2f127e%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADhq2b5cU_Ce6g_9k%2BHeCfgNSFbOV3YFtpAffoAsHsEhwNwi5A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Would a patch to add allow_empty_strings=True to CharField be accepted?

[Luke Benstead]

Hi!

We've recently hit upon a problem where we need empty strings in a 
CharField to be coerced to NULL. Obviously nullable CharField's are frowned 
upon but we have the requirement that non-empty values must be unique, so 
the empty state must be NULL. 

We've written a custom subclass of CharField to deal with this, but when I 
found the bug report[1] for this issue, the wontfix justification was that 
it would make things backwards incompatible. What I'm proposing instead is 
we add another option to CharField's __init__ which defaults to true called 
"allow_empty_strings". If set to False, and the field is nullable, this 
would coerce empty values to None. If the field was not nullable, this 
would raise an exception (ValueError?, IntegrityError?). 

Is this an acceptable solution to support this use-case?

Thanks,

Luke.

[1] https://code.djangoproject.com/ticket/9590

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ad3d155c-6386-4d4f-a4f3-07544c2f127e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.