Re: status of 1.8 release blockers

2015-03-28 Thread Tim Graham
We've fixed four small issues in the 1.8 branch since the release candidate 
(with no other reported blockers), so I am optimistic we’ll be able to 
release 1.8 final on Wednesday as scheduled.

On Saturday, March 14, 2015 at 4:45:21 PM UTC-4, Tim Graham wrote:
>
> Good news: just one new release blocker this week (#24469) which is 
> awaiting a final review from Aymeric. I'm targeting Wednesday of next week 
> for the release candidate as well as a bug fix release for 1.7 (may be the 
> last one, before 1.7 switches to security updates only).
>
> On Saturday, March 7, 2015 at 10:54:30 AM UTC-5, Tim Graham wrote:
>>
>> With about 10 days to go until the scheduled date for the release 
>> candidate (Monday, March 16), there's just one blocker that Anssi's working 
>> on (looks like tests aren't passing yet) [#24171]. About 7 issues have been 
>> fixed in 1.8 since the beta release.
>>
>> On Wednesday, February 25, 2015 at 3:43:15 AM UTC-5, raulcd wrote:
>>>
>>> \o/
>>>
>>> On Wed, Feb 25, 2015 at 1:08 AM, Tim Graham  wrote:
>>>
 Zero blockers as of this writing. If we survive the next 12 hours with 
 no new ones, I'll release the beta around then (famous last words).


 On Monday, February 23, 2015 at 7:29:09 PM UTC-5, Tim Graham wrote:
>
> Previous two issues have been fixed, and now we have two new issues:
>
> #24391  UUIDField with 
> default=uuid4 triggers validation on otherwise empty inline formsets 
> 
>
> #24395  Cannot reference 
> FK relation from inline ModelForm.save() 
> 
>
> There is a chance to resolve them both tomorrow and then release the 
> beta.
>
> On Saturday, February 21, 2015 at 3:53:51 PM UTC-5, Tim Graham wrote:
>>
>> Patches for the two remaining blockers are awaiting review.
>>
>> #24381  Cache pickling 
>> exception in 1.8a1 with cross-table filter params 
>> 
>> #24377  UUIDField as 
>> primary key breaks inline admins 
>> 
>>
>> On Friday, February 20, 2015 at 4:48:01 PM UTC-5, Tim Graham wrote:
>>>
>>> The three issues from last time are resolved, but there is a new 
>>> issue I've been working on today. I have a tentative fix, but there is 
>>> a 
>>> failing test. Assuming nothing else comes up, I might consider 
>>> releasing 
>>> the beta tomorrow even if I can't solve that by then as it's not really 
>>> a 
>>> new issue, just magnified by the fact that UUIDField is in core and 
>>> that 
>>> it's implementation as a primary_key requires default=uuid.uuid4 unlike 
>>> some existing third-party implementations.
>>>
>>> #24377  UUIDField as 
>>> primary key breaks inline admins 
>>> 
>>>
>>> On Thursday, February 19, 2015 at 2:45:07 AM UTC-5, Loïc Bistuer 
>>> wrote:

 From my point of view #24351 is ready for a final sanity check and 
 merging. 

 -- 
 Loïc 

 > On Feb 19, 2015, at 10:10, Tim Graham  
 wrote: 
 > 
 > 3 issues remain. I haven't confirmed with the owners, but it 
 seems to me there may be a good chance to wrap them up tomorrow. 
 > 
 > 
 > #24351  RunPython/RunSQL operations in contrib migrations 
 and multi-db routers. 
 > Owner: Loic 
 > Status: In review. 
 > 
 > 
 > #24328 The new Options._get_fields() method needs to be cleaned 
 up 
 > Owner: Anssi 
 > Status: In review. 
 > 
 > #24343 UUID foreign key accessor returns inconsistent type 
 > 
 > Owner: Marc 
 > Status: Marc to polish patch. 
 > 
 > -- 
 > 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-develop...@googlegroups.com. 
 > To post to this group, send email to django-d...@googlegroups.com. 

 > Visit this group at http://groups.google.com/
 group/django-developers. 
 > To view this discussion on the web visit 
 https://groups.google.com/d/msgid/django-developers/
 170625d3-1bb5-4b9d-ab74-501fd5dea86b%40googlegroups.com. 
 > For more options, visit 

Re: status of 1.8 release blockers

2015-03-14 Thread Tim Graham
Good news: just one new release blocker this week (#24469) which is 
awaiting a final review from Aymeric. I'm targeting Wednesday of next week 
for the release candidate as well as a bug fix release for 1.7 (may be the 
last one, before 1.7 switches to security updates only).

On Saturday, March 7, 2015 at 10:54:30 AM UTC-5, Tim Graham wrote:
>
> With about 10 days to go until the scheduled date for the release 
> candidate (Monday, March 16), there's just one blocker that Anssi's working 
> on (looks like tests aren't passing yet) [#24171]. About 7 issues have been 
> fixed in 1.8 since the beta release.
>
> On Wednesday, February 25, 2015 at 3:43:15 AM UTC-5, raulcd wrote:
>>
>> \o/
>>
>> On Wed, Feb 25, 2015 at 1:08 AM, Tim Graham  wrote:
>>
>>> Zero blockers as of this writing. If we survive the next 12 hours with 
>>> no new ones, I'll release the beta around then (famous last words).
>>>
>>>
>>> On Monday, February 23, 2015 at 7:29:09 PM UTC-5, Tim Graham wrote:

 Previous two issues have been fixed, and now we have two new issues:

 #24391  UUIDField with 
 default=uuid4 triggers validation on otherwise empty inline formsets 
 

 #24395  Cannot reference 
 FK relation from inline ModelForm.save() 
 

 There is a chance to resolve them both tomorrow and then release the 
 beta.

 On Saturday, February 21, 2015 at 3:53:51 PM UTC-5, Tim Graham wrote:
>
> Patches for the two remaining blockers are awaiting review.
>
> #24381  Cache pickling 
> exception in 1.8a1 with cross-table filter params 
> 
> #24377  UUIDField as 
> primary key breaks inline admins 
> 
>
> On Friday, February 20, 2015 at 4:48:01 PM UTC-5, Tim Graham wrote:
>>
>> The three issues from last time are resolved, but there is a new 
>> issue I've been working on today. I have a tentative fix, but there is a 
>> failing test. Assuming nothing else comes up, I might consider releasing 
>> the beta tomorrow even if I can't solve that by then as it's not really 
>> a 
>> new issue, just magnified by the fact that UUIDField is in core and that 
>> it's implementation as a primary_key requires default=uuid.uuid4 unlike 
>> some existing third-party implementations.
>>
>> #24377  UUIDField as 
>> primary key breaks inline admins 
>> 
>>
>> On Thursday, February 19, 2015 at 2:45:07 AM UTC-5, Loïc Bistuer 
>> wrote:
>>>
>>> From my point of view #24351 is ready for a final sanity check and 
>>> merging. 
>>>
>>> -- 
>>> Loïc 
>>>
>>> > On Feb 19, 2015, at 10:10, Tim Graham  wrote: 
>>> > 
>>> > 3 issues remain. I haven't confirmed with the owners, but it seems 
>>> to me there may be a good chance to wrap them up tomorrow. 
>>> > 
>>> > 
>>> > #24351  RunPython/RunSQL operations in contrib migrations 
>>> and multi-db routers. 
>>> > Owner: Loic 
>>> > Status: In review. 
>>> > 
>>> > 
>>> > #24328 The new Options._get_fields() method needs to be cleaned up 
>>> > Owner: Anssi 
>>> > Status: In review. 
>>> > 
>>> > #24343 UUID foreign key accessor returns inconsistent type 
>>> > 
>>> > Owner: Marc 
>>> > Status: Marc to polish patch. 
>>> > 
>>> > -- 
>>> > 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-develop...@googlegroups.com. 
>>> > To post to this group, send email to django-d...@googlegroups.com. 
>>>
>>> > Visit this group at http://groups.google.com/
>>> group/django-developers. 
>>> > To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/
>>> 170625d3-1bb5-4b9d-ab74-501fd5dea86b%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-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at 

Re: status of 1.8 release blockers

2015-03-07 Thread Tim Graham
With about 10 days to go until the scheduled date for the release candidate 
(Monday, March 16), there's just one blocker that Anssi's working on (looks 
like tests aren't passing yet) [#24171]. About 7 issues have been fixed in 
1.8 since the beta release.

On Wednesday, February 25, 2015 at 3:43:15 AM UTC-5, raulcd wrote:
>
> \o/
>
> On Wed, Feb 25, 2015 at 1:08 AM, Tim Graham  > wrote:
>
>> Zero blockers as of this writing. If we survive the next 12 hours with no 
>> new ones, I'll release the beta around then (famous last words).
>>
>>
>> On Monday, February 23, 2015 at 7:29:09 PM UTC-5, Tim Graham wrote:
>>>
>>> Previous two issues have been fixed, and now we have two new issues:
>>>
>>> #24391  UUIDField with 
>>> default=uuid4 triggers validation on otherwise empty inline formsets 
>>> 
>>>
>>> #24395  Cannot reference 
>>> FK relation from inline ModelForm.save() 
>>> 
>>>
>>> There is a chance to resolve them both tomorrow and then release the 
>>> beta.
>>>
>>> On Saturday, February 21, 2015 at 3:53:51 PM UTC-5, Tim Graham wrote:

 Patches for the two remaining blockers are awaiting review.

 #24381  Cache pickling 
 exception in 1.8a1 with cross-table filter params 
 
 #24377  UUIDField as 
 primary key breaks inline admins 
 

 On Friday, February 20, 2015 at 4:48:01 PM UTC-5, Tim Graham wrote:
>
> The three issues from last time are resolved, but there is a new issue 
> I've been working on today. I have a tentative fix, but there is a 
> failing 
> test. Assuming nothing else comes up, I might consider releasing the beta 
> tomorrow even if I can't solve that by then as it's not really a new 
> issue, 
> just magnified by the fact that UUIDField is in core and that it's 
> implementation as a primary_key requires default=uuid.uuid4 unlike some 
> existing third-party implementations.
>
> #24377  UUIDField as 
> primary key breaks inline admins 
> 
>
> On Thursday, February 19, 2015 at 2:45:07 AM UTC-5, Loïc Bistuer wrote:
>>
>> From my point of view #24351 is ready for a final sanity check and 
>> merging. 
>>
>> -- 
>> Loïc 
>>
>> > On Feb 19, 2015, at 10:10, Tim Graham  wrote: 
>> > 
>> > 3 issues remain. I haven't confirmed with the owners, but it seems 
>> to me there may be a good chance to wrap them up tomorrow. 
>> > 
>> > 
>> > #24351  RunPython/RunSQL operations in contrib migrations 
>> and multi-db routers. 
>> > Owner: Loic 
>> > Status: In review. 
>> > 
>> > 
>> > #24328 The new Options._get_fields() method needs to be cleaned up 
>> > Owner: Anssi 
>> > Status: In review. 
>> > 
>> > #24343 UUID foreign key accessor returns inconsistent type 
>> > 
>> > Owner: Marc 
>> > Status: Marc to polish patch. 
>> > 
>> > -- 
>> > 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-develop...@googlegroups.com. 
>> > To post to this group, send email to django-d...@googlegroups.com. 
>> > Visit this group at http://groups.google.com/
>> group/django-developers. 
>> > To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/
>> 170625d3-1bb5-4b9d-ab74-501fd5dea86b%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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/7d933ca2-ed55-408b-bdce-551060e24d54%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to 

Re: status of 1.8 release blockers

2015-02-25 Thread Raúl Cumplido
\o/

On Wed, Feb 25, 2015 at 1:08 AM, Tim Graham  wrote:

> Zero blockers as of this writing. If we survive the next 12 hours with no
> new ones, I'll release the beta around then (famous last words).
>
>
> On Monday, February 23, 2015 at 7:29:09 PM UTC-5, Tim Graham wrote:
>>
>> Previous two issues have been fixed, and now we have two new issues:
>>
>> #24391  UUIDField with
>> default=uuid4 triggers validation on otherwise empty inline formsets
>> 
>>
>> #24395  Cannot reference FK
>> relation from inline ModelForm.save()
>> 
>>
>> There is a chance to resolve them both tomorrow and then release the beta.
>>
>> On Saturday, February 21, 2015 at 3:53:51 PM UTC-5, Tim Graham wrote:
>>>
>>> Patches for the two remaining blockers are awaiting review.
>>>
>>> #24381  Cache pickling
>>> exception in 1.8a1 with cross-table filter params
>>> 
>>> #24377  UUIDField as
>>> primary key breaks inline admins
>>> 
>>>
>>> On Friday, February 20, 2015 at 4:48:01 PM UTC-5, Tim Graham wrote:

 The three issues from last time are resolved, but there is a new issue
 I've been working on today. I have a tentative fix, but there is a failing
 test. Assuming nothing else comes up, I might consider releasing the beta
 tomorrow even if I can't solve that by then as it's not really a new issue,
 just magnified by the fact that UUIDField is in core and that it's
 implementation as a primary_key requires default=uuid.uuid4 unlike some
 existing third-party implementations.

 #24377  UUIDField as
 primary key breaks inline admins
 

 On Thursday, February 19, 2015 at 2:45:07 AM UTC-5, Loïc Bistuer wrote:
>
> From my point of view #24351 is ready for a final sanity check and
> merging.
>
> --
> Loïc
>
> > On Feb 19, 2015, at 10:10, Tim Graham  wrote:
> >
> > 3 issues remain. I haven't confirmed with the owners, but it seems
> to me there may be a good chance to wrap them up tomorrow.
> >
> >
> > #24351  RunPython/RunSQL operations in contrib migrations
> and multi-db routers.
> > Owner: Loic
> > Status: In review.
> >
> >
> > #24328 The new Options._get_fields() method needs to be cleaned up
> > Owner: Anssi
> > Status: In review.
> >
> > #24343 UUID foreign key accessor returns inconsistent type
> >
> > Owner: Marc
> > Status: Marc to polish patch.
> >
> > --
> > 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-develop...@googlegroups.com.
> > To post to this group, send email to django-d...@googlegroups.com.
> > Visit this group at http://groups.google.com/group/django-developers.
>
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/
> 170625d3-1bb5-4b9d-ab74-501fd5dea86b%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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/7d933ca2-ed55-408b-bdce-551060e24d54%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 

Re: status of 1.8 release blockers

2015-02-24 Thread Tim Graham
Zero blockers as of this writing. If we survive the next 12 hours with no 
new ones, I'll release the beta around then (famous last words).

On Monday, February 23, 2015 at 7:29:09 PM UTC-5, Tim Graham wrote:
>
> Previous two issues have been fixed, and now we have two new issues:
>
> #24391  UUIDField with 
> default=uuid4 triggers validation on otherwise empty inline formsets 
> 
>
> #24395  Cannot reference FK 
> relation from inline ModelForm.save() 
> 
>
> There is a chance to resolve them both tomorrow and then release the beta.
>
> On Saturday, February 21, 2015 at 3:53:51 PM UTC-5, Tim Graham wrote:
>>
>> Patches for the two remaining blockers are awaiting review.
>>
>> #24381  Cache pickling 
>> exception in 1.8a1 with cross-table filter params 
>> 
>> #24377  UUIDField as 
>> primary key breaks inline admins 
>> 
>>
>> On Friday, February 20, 2015 at 4:48:01 PM UTC-5, Tim Graham wrote:
>>>
>>> The three issues from last time are resolved, but there is a new issue 
>>> I've been working on today. I have a tentative fix, but there is a failing 
>>> test. Assuming nothing else comes up, I might consider releasing the beta 
>>> tomorrow even if I can't solve that by then as it's not really a new issue, 
>>> just magnified by the fact that UUIDField is in core and that it's 
>>> implementation as a primary_key requires default=uuid.uuid4 unlike some 
>>> existing third-party implementations.
>>>
>>> #24377  UUIDField as 
>>> primary key breaks inline admins 
>>> 
>>>
>>> On Thursday, February 19, 2015 at 2:45:07 AM UTC-5, Loïc Bistuer wrote:

 From my point of view #24351 is ready for a final sanity check and 
 merging. 

 -- 
 Loïc 

 > On Feb 19, 2015, at 10:10, Tim Graham  wrote: 
 > 
 > 3 issues remain. I haven't confirmed with the owners, but it seems to 
 me there may be a good chance to wrap them up tomorrow. 
 > 
 > 
 > #24351  RunPython/RunSQL operations in contrib migrations and 
 multi-db routers. 
 > Owner: Loic 
 > Status: In review. 
 > 
 > 
 > #24328 The new Options._get_fields() method needs to be cleaned up 
 > Owner: Anssi 
 > Status: In review. 
 > 
 > #24343 UUID foreign key accessor returns inconsistent type 
 > 
 > Owner: Marc 
 > Status: Marc to polish patch. 
 > 
 > -- 
 > 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-develop...@googlegroups.com. 
 > To post to this group, send email to django-d...@googlegroups.com. 
 > Visit this group at http://groups.google.com/group/django-developers. 

 > To view this discussion on the web visit 
 https://groups.google.com/d/msgid/django-developers/170625d3-1bb5-4b9d-ab74-501fd5dea86b%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7d933ca2-ed55-408b-bdce-551060e24d54%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: status of 1.8 release blockers

2015-02-23 Thread Tim Graham
Previous two issues have been fixed, and now we have two new issues:

#24391  UUIDField with 
default=uuid4 triggers validation on otherwise empty inline formsets 


#24395  Cannot reference FK 
relation from inline ModelForm.save() 


There is a chance to resolve them both tomorrow and then release the beta.

On Saturday, February 21, 2015 at 3:53:51 PM UTC-5, Tim Graham wrote:
>
> Patches for the two remaining blockers are awaiting review.
>
> #24381  Cache pickling 
> exception in 1.8a1 with cross-table filter params 
> 
> #24377  UUIDField as primary 
> key breaks inline admins 
>
> On Friday, February 20, 2015 at 4:48:01 PM UTC-5, Tim Graham wrote:
>>
>> The three issues from last time are resolved, but there is a new issue 
>> I've been working on today. I have a tentative fix, but there is a failing 
>> test. Assuming nothing else comes up, I might consider releasing the beta 
>> tomorrow even if I can't solve that by then as it's not really a new issue, 
>> just magnified by the fact that UUIDField is in core and that it's 
>> implementation as a primary_key requires default=uuid.uuid4 unlike some 
>> existing third-party implementations.
>>
>> #24377  UUIDField as 
>> primary key breaks inline admins 
>> 
>>
>> On Thursday, February 19, 2015 at 2:45:07 AM UTC-5, Loïc Bistuer wrote:
>>>
>>> From my point of view #24351 is ready for a final sanity check and 
>>> merging. 
>>>
>>> -- 
>>> Loïc 
>>>
>>> > On Feb 19, 2015, at 10:10, Tim Graham  wrote: 
>>> > 
>>> > 3 issues remain. I haven't confirmed with the owners, but it seems to 
>>> me there may be a good chance to wrap them up tomorrow. 
>>> > 
>>> > 
>>> > #24351  RunPython/RunSQL operations in contrib migrations and 
>>> multi-db routers. 
>>> > Owner: Loic 
>>> > Status: In review. 
>>> > 
>>> > 
>>> > #24328 The new Options._get_fields() method needs to be cleaned up 
>>> > Owner: Anssi 
>>> > Status: In review. 
>>> > 
>>> > #24343 UUID foreign key accessor returns inconsistent type 
>>> > 
>>> > Owner: Marc 
>>> > Status: Marc to polish patch. 
>>> > 
>>> > -- 
>>> > 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-develop...@googlegroups.com. 
>>> > To post to this group, send email to django-d...@googlegroups.com. 
>>> > Visit this group at http://groups.google.com/group/django-developers. 
>>> > To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/170625d3-1bb5-4b9d-ab74-501fd5dea86b%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e0da03c2-9bf1-48ca-b9e4-efebb5499f61%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: status of 1.8 release blockers

2015-02-21 Thread Tim Graham
Patches for the two remaining blockers are awaiting review.

#24381  Cache pickling 
exception in 1.8a1 with cross-table filter params 

#24377  UUIDField as primary 
key breaks inline admins 

On Friday, February 20, 2015 at 4:48:01 PM UTC-5, Tim Graham wrote:
>
> The three issues from last time are resolved, but there is a new issue 
> I've been working on today. I have a tentative fix, but there is a failing 
> test. Assuming nothing else comes up, I might consider releasing the beta 
> tomorrow even if I can't solve that by then as it's not really a new issue, 
> just magnified by the fact that UUIDField is in core and that it's 
> implementation as a primary_key requires default=uuid.uuid4 unlike some 
> existing third-party implementations.
>
> #24377  UUIDField as primary 
> key breaks inline admins 
>
> On Thursday, February 19, 2015 at 2:45:07 AM UTC-5, Loïc Bistuer wrote:
>>
>> From my point of view #24351 is ready for a final sanity check and 
>> merging. 
>>
>> -- 
>> Loïc 
>>
>> > On Feb 19, 2015, at 10:10, Tim Graham  wrote: 
>> > 
>> > 3 issues remain. I haven't confirmed with the owners, but it seems to 
>> me there may be a good chance to wrap them up tomorrow. 
>> > 
>> > 
>> > #24351  RunPython/RunSQL operations in contrib migrations and 
>> multi-db routers. 
>> > Owner: Loic 
>> > Status: In review. 
>> > 
>> > 
>> > #24328 The new Options._get_fields() method needs to be cleaned up 
>> > Owner: Anssi 
>> > Status: In review. 
>> > 
>> > #24343 UUID foreign key accessor returns inconsistent type 
>> > 
>> > Owner: Marc 
>> > Status: Marc to polish patch. 
>> > 
>> > -- 
>> > 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-develop...@googlegroups.com. 
>> > To post to this group, send email to django-d...@googlegroups.com. 
>> > Visit this group at http://groups.google.com/group/django-developers. 
>> > To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/170625d3-1bb5-4b9d-ab74-501fd5dea86b%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2f6e3b20-674a-43a0-b2c1-08c0db5980df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: status of 1.8 release blockers

2015-02-20 Thread Tim Graham
The three issues from last time are resolved, but there is a new issue I've 
been working on today. I have a tentative fix, but there is a failing test. 
Assuming nothing else comes up, I might consider releasing the beta 
tomorrow even if I can't solve that by then as it's not really a new issue, 
just magnified by the fact that UUIDField is in core and that it's 
implementation as a primary_key requires default=uuid.uuid4 unlike some 
existing third-party implementations.

#24377  UUIDField as primary 
key breaks inline admins 

On Thursday, February 19, 2015 at 2:45:07 AM UTC-5, Loïc Bistuer wrote:
>
> From my point of view #24351 is ready for a final sanity check and 
> merging. 
>
> -- 
> Loïc 
>
> > On Feb 19, 2015, at 10:10, Tim Graham  
> wrote: 
> > 
> > 3 issues remain. I haven't confirmed with the owners, but it seems to me 
> there may be a good chance to wrap them up tomorrow. 
> > 
> > 
> > #24351  RunPython/RunSQL operations in contrib migrations and 
> multi-db routers. 
> > Owner: Loic 
> > Status: In review. 
> > 
> > 
> > #24328 The new Options._get_fields() method needs to be cleaned up 
> > Owner: Anssi 
> > Status: In review. 
> > 
> > #24343 UUID foreign key accessor returns inconsistent type 
> > 
> > Owner: Marc 
> > Status: Marc to polish patch. 
> > 
> > -- 
> > 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-develop...@googlegroups.com . 
> > To post to this group, send email to django-d...@googlegroups.com 
> . 
> > Visit this group at http://groups.google.com/group/django-developers. 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/170625d3-1bb5-4b9d-ab74-501fd5dea86b%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1214a546-e315-4b54-8685-fa2ae659d497%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: status of 1.8 release blockers

2015-02-18 Thread Loïc Bistuer
>From my point of view #24351 is ready for a final sanity check and merging.

-- 
Loïc

> On Feb 19, 2015, at 10:10, Tim Graham  wrote:
> 
> 3 issues remain. I haven't confirmed with the owners, but it seems to me 
> there may be a good chance to wrap them up tomorrow.
> 
> 
> #24351  RunPython/RunSQL operations in contrib migrations and 
> multi-db routers.
> Owner: Loic
> Status: In review.
> 
> 
> #24328 The new Options._get_fields() method needs to be cleaned up
> Owner: Anssi
> Status: In review.
> 
> #24343 UUID foreign key accessor returns inconsistent type
> 
> Owner: Marc
> Status: Marc to polish patch.
> 
> -- 
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/170625d3-1bb5-4b9d-ab74-501fd5dea86b%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/136699C8-42D8-47E9-B0A6-78C8E7BA96A3%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: status of 1.8 release blockers

2015-02-18 Thread Tim Graham
3 issues remain. I haven't confirmed with the owners, but it seems to me 
there may be a good chance to wrap them up tomorrow.


#24351    RunPython/RunSQL 
operations in contrib migrations and multi-db routers. 
Owner: Loic
Status: In review.


#24328  The new 
Options._get_fields() method needs to be cleaned up 

Owner: Anssi
Status: In review.

#24343  UUID foreign key 
accessor returns inconsistent type 
Owner: Marc
Status: Marc to polish patch.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/170625d3-1bb5-4b9d-ab74-501fd5dea86b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: status of 1.8 release blockers

2015-02-17 Thread Tim Graham
Today's update:

Rrelease tomorrow seems unlikely -- let's target Friday and if we finish 
earlier, that's a bonus.

#24307  Oracle Syncdb breaks 
trying to set NULL to column that already is NULL 

Owner: Shai
Status: Fix written; working on a test.

#24324  Crashes when project 
path or path to Django install contains a non-ascii character 

Owner: Tim
Status: Mostly committed. Waiting for reply from Berker regarding a couple 
of his review comments.


#24351    RunPython/RunSQL 
operations in contrib migrations and multi-db routers. 
Owner: Loic
Status: Waiting for feedback on API design (see mailing list thread).

#24328  The new 
Options._get_fields() method needs to be cleaned up 

Owner: Anssi
Status: Patch still in progress.

#24343  UUID foreign key 
accessor returns inconsistent type 
Owner: Marc/Josh/Shai
Status: Josh thinks the patch is RFC. Awaiting final review from anyone 
interested.

#24291  Migrations fail with 
unused swappable model 
Owner: Markus
Status: Patch looks good to me (again).

On Tuesday, February 17, 2015 at 12:40:40 PM UTC-5, Marten Kenbeek wrote:
>
> @Tim I believe it's quite easy actually, I've fixed my original patch and 
> it's just waiting to be reviewed. It's available at 
> https://github.com/django/django/pull/4071. However, it's a very rare bug 
> and I only encountered it in the tests when working on another issue, not 
> in any real project. Not really worth delaying the beta I think, I'm 
> getting the feeling you guys are busy enough as it is. 
>
> Op dinsdag 17 februari 2015 18:20:22 UTC+1 schreef Tim Graham:
>>
>> If it's the only release blocker left and the fix is difficult, I think 
>> we could issue a beta release without it. I think the worst case is that 
>> you'll get some duplicate bug reports from testers.
>>
>> On Tuesday, February 17, 2015 at 10:06:27 AM UTC-5, Markus Holtermann 
>> wrote:
>>>
>>> So, it turns out that #24291 (Migrations fail with unused swappable 
>>> model)  only occurs when a 
>>> swapped out model doesn't define an explicit model manager. Since auth.User 
>>> is the only model that is officially supported for "swappiness" and it 
>>> defines an explicit UserManager this isn't really a problem in my opinion. 
>>> Since the whole swappable model API is internal API anyway, I don't want to 
>>> rule this issue a release blocker. If projects in the wild use the 
>>> swappable model API they can get around the issue by adding `objects = 
>>> models.Manager()` to that model.
>>>
>>> Tim, Russ, thoughts 'bout that?
>>>
>>> /Markus
>>>
>>> On Tuesday, February 17, 2015 at 1:05:37 AM UTC+1, Tim Graham wrote:

 Here's the status on blockers. Given the work that remains, I don't 
 foresee the beta release happening earlier than Wednesday, but the next 
 update of this thread will be tomorrow.

 #24324  Crashes when 
 project path or path to Django install contains a non-ascii character 
 
 Owner: Tim
 Status: Patch needs review


 #24351    RunPython/RunSQL 
 operations in contrib migrations and multi-db routers. 
 Owner: Loic
 Status: API design decision needed. Time permitting, Loic will write to 
 the mailing list on this tomorrow.

 #24328  The new 
 Options._get_fields() method needs to be cleaned up 
 
 Owner: Anssi
 Status: Anssi still reviewing the patch; decision may be needed on 
 backwards compatibility of get_fields().

 #24343  UUID foreign key 
 accessor returns inconsistent type 
 Owner: Marc/Josh/Shai
 Status: Josh working on cleaning up the patch. Review/feedback from 
 Anssi requested.

 #24291 
 
  Migrations 
 fail with unused swappable model 
 
 Owner: Markus
 Status: Patch looks good to me; Markus to review & commit tomorrow.

 On Monday, February 16, 2015 at 11:12:46 

Re: status of 1.8 release blockers

2015-02-17 Thread Marten Kenbeek
@Tim I believe it's quite easy actually, I've fixed my original patch and 
it's just waiting to be reviewed. It's available at 
https://github.com/django/django/pull/4071. However, it's a very rare bug 
and I only encountered it in the tests when working on another issue, not 
in any real project. Not really worth delaying the beta I think, I'm 
getting the feeling you guys are busy enough as it is. 

Op dinsdag 17 februari 2015 18:20:22 UTC+1 schreef Tim Graham:
>
> If it's the only release blocker left and the fix is difficult, I think we 
> could issue a beta release without it. I think the worst case is that 
> you'll get some duplicate bug reports from testers.
>
> On Tuesday, February 17, 2015 at 10:06:27 AM UTC-5, Markus Holtermann 
> wrote:
>>
>> So, it turns out that #24291 (Migrations fail with unused swappable 
>> model)  only occurs when a 
>> swapped out model doesn't define an explicit model manager. Since auth.User 
>> is the only model that is officially supported for "swappiness" and it 
>> defines an explicit UserManager this isn't really a problem in my opinion. 
>> Since the whole swappable model API is internal API anyway, I don't want to 
>> rule this issue a release blocker. If projects in the wild use the 
>> swappable model API they can get around the issue by adding `objects = 
>> models.Manager()` to that model.
>>
>> Tim, Russ, thoughts 'bout that?
>>
>> /Markus
>>
>> On Tuesday, February 17, 2015 at 1:05:37 AM UTC+1, Tim Graham wrote:
>>>
>>> Here's the status on blockers. Given the work that remains, I don't 
>>> foresee the beta release happening earlier than Wednesday, but the next 
>>> update of this thread will be tomorrow.
>>>
>>> #24324  Crashes when 
>>> project path or path to Django install contains a non-ascii character 
>>> 
>>> Owner: Tim
>>> Status: Patch needs review
>>>
>>>
>>> #24351    RunPython/RunSQL 
>>> operations in contrib migrations and multi-db routers. 
>>> Owner: Loic
>>> Status: API design decision needed. Time permitting, Loic will write to 
>>> the mailing list on this tomorrow.
>>>
>>> #24328  The new 
>>> Options._get_fields() method needs to be cleaned up 
>>> 
>>> Owner: Anssi
>>> Status: Anssi still reviewing the patch; decision may be needed on 
>>> backwards compatibility of get_fields().
>>>
>>> #24343  UUID foreign key 
>>> accessor returns inconsistent type 
>>> Owner: Marc/Josh/Shai
>>> Status: Josh working on cleaning up the patch. Review/feedback from 
>>> Anssi requested.
>>>
>>> #24291 
>>> 
>>>  Migrations 
>>> fail with unused swappable model 
>>> 
>>> Owner: Markus
>>> Status: Patch looks good to me; Markus to review & commit tomorrow.
>>>
>>> On Monday, February 16, 2015 at 11:12:46 AM UTC-5, Tim Graham wrote:

 There are still quite a few unresolved issues, so the beta release 
 won't happen today. I'll send an update at the end of the day with the 
 status of the remaining issues.

 On Friday, February 13, 2015 at 1:30:44 PM UTC-5, Markus Holtermann 
 wrote:
>
> Hey folks,
>
> I looked into the issues #24225, #24264 and #24282 and have a working 
> pull request ready for review: 
> https://github.com/django/django/pull/4097
>
> The essential change in the pull request is the way how the set of 
> models that needs to be rerendered is constructed. Instead of naively 
> only 
> resolving one level of relations (Only rerender B and C if C changed: A 
> --> 
> B --> C) the new approach recursively checks for relational fields 
> (forwards and reverse relations (e.g. ForeignKey and ManyToManyRel)) as 
> well as inheritance.
>
> This approach boils down to the following behavior:
>
> If a completely standalone model (no incoming or outgoing relations 
> and no subclasses and only a directed subclass of models.Model) changes, 
> only this model will be rerendered, which is the best case scenario. If 
> every model is somehow related (directly or through other models) to 
> every 
> other model, e.g. through the user model, changing one model from that 
> set 
> will require *all* models to be rerendered, which is the worst case 
> scenario and results in the similar behavior as 1.7.
>
> To get that pull request into the 1.8 beta I ask everybody to take a 
> look and try it out on their projects. Especially if 1.8 alpha 1 

Re: status of 1.8 release blockers

2015-02-17 Thread Tim Graham
If it's the only release blocker left and the fix is difficult, I think we 
could issue a beta release without it. I think the worst case is that 
you'll get some duplicate bug reports from testers.

On Tuesday, February 17, 2015 at 10:06:27 AM UTC-5, Markus Holtermann wrote:
>
> So, it turns out that #24291 (Migrations fail with unused swappable model) 
>  only occurs when a swapped 
> out model doesn't define an explicit model manager. Since auth.User is the 
> only model that is officially supported for "swappiness" and it defines an 
> explicit UserManager this isn't really a problem in my opinion. Since the 
> whole swappable model API is internal API anyway, I don't want to rule this 
> issue a release blocker. If projects in the wild use the swappable model 
> API they can get around the issue by adding `objects = models.Manager()` to 
> that model.
>
> Tim, Russ, thoughts 'bout that?
>
> /Markus
>
> On Tuesday, February 17, 2015 at 1:05:37 AM UTC+1, Tim Graham wrote:
>>
>> Here's the status on blockers. Given the work that remains, I don't 
>> foresee the beta release happening earlier than Wednesday, but the next 
>> update of this thread will be tomorrow.
>>
>> #24324  Crashes when 
>> project path or path to Django install contains a non-ascii character 
>> 
>> Owner: Tim
>> Status: Patch needs review
>>
>>
>> #24351    RunPython/RunSQL 
>> operations in contrib migrations and multi-db routers. 
>> Owner: Loic
>> Status: API design decision needed. Time permitting, Loic will write to 
>> the mailing list on this tomorrow.
>>
>> #24328  The new 
>> Options._get_fields() method needs to be cleaned up 
>> 
>> Owner: Anssi
>> Status: Anssi still reviewing the patch; decision may be needed on 
>> backwards compatibility of get_fields().
>>
>> #24343  UUID foreign key 
>> accessor returns inconsistent type 
>> Owner: Marc/Josh/Shai
>> Status: Josh working on cleaning up the patch. Review/feedback from Anssi 
>> requested.
>>
>> #24291 
>> 
>>  Migrations 
>> fail with unused swappable model 
>> 
>> Owner: Markus
>> Status: Patch looks good to me; Markus to review & commit tomorrow.
>>
>> On Monday, February 16, 2015 at 11:12:46 AM UTC-5, Tim Graham wrote:
>>>
>>> There are still quite a few unresolved issues, so the beta release won't 
>>> happen today. I'll send an update at the end of the day with the status of 
>>> the remaining issues.
>>>
>>> On Friday, February 13, 2015 at 1:30:44 PM UTC-5, Markus Holtermann 
>>> wrote:

 Hey folks,

 I looked into the issues #24225, #24264 and #24282 and have a working 
 pull request ready for review: 
 https://github.com/django/django/pull/4097

 The essential change in the pull request is the way how the set of 
 models that needs to be rerendered is constructed. Instead of naively only 
 resolving one level of relations (Only rerender B and C if C changed: A 
 --> 
 B --> C) the new approach recursively checks for relational fields 
 (forwards and reverse relations (e.g. ForeignKey and ManyToManyRel)) as 
 well as inheritance.

 This approach boils down to the following behavior:

 If a completely standalone model (no incoming or outgoing relations and 
 no subclasses and only a directed subclass of models.Model) changes, only 
 this model will be rerendered, which is the best case scenario. If every 
 model is somehow related (directly or through other models) to every other 
 model, e.g. through the user model, changing one model from that set will 
 require *all* models to be rerendered, which is the worst case 
 scenario and results in the similar behavior as 1.7.

 To get that pull request into the 1.8 beta I ask everybody to take a 
 look and try it out on their projects. Especially if 1.8 alpha 1 didn't 
 work for you.

 Thanks

 /Markus

 On Saturday, December 20, 2014 at 8:40:33 PM UTC+1, Tim Graham wrote:
>
> As we approach the date for 1.8 alpha, I plan to send a weekly update 
> on the status of release blocking issues.
>
> We currently have 3 release blockers affecting master. You can use 
> this Trac filter to see them:
>
> https://code.djangoproject.com/query?status=assigned=new=master=Release+blocker
>
> You can also see other tickets we are targeting for 1.8 with this 
> filter. This includes some of 

Re: status of 1.8 release blockers

2015-02-17 Thread Markus Holtermann
So, it turns out that #24291 (Migrations fail with unused swappable model) 
 only occurs when a swapped 
out model doesn't define an explicit model manager. Since auth.User is the 
only model that is officially supported for "swappiness" and it defines an 
explicit UserManager this isn't really a problem in my opinion. Since the 
whole swappable model API is internal API anyway, I don't want to rule this 
issue a release blocker. If projects in the wild use the swappable model 
API they can get around the issue by adding `objects = models.Manager()` to 
that model.

Tim, Russ, thoughts 'bout that?

/Markus

On Tuesday, February 17, 2015 at 1:05:37 AM UTC+1, Tim Graham wrote:
>
> Here's the status on blockers. Given the work that remains, I don't 
> foresee the beta release happening earlier than Wednesday, but the next 
> update of this thread will be tomorrow.
>
> #24324  Crashes when project 
> path or path to Django install contains a non-ascii character 
> 
> Owner: Tim
> Status: Patch needs review
>
>
> #24351    RunPython/RunSQL 
> operations in contrib migrations and multi-db routers. 
> Owner: Loic
> Status: API design decision needed. Time permitting, Loic will write to 
> the mailing list on this tomorrow.
>
> #24328  The new 
> Options._get_fields() method needs to be cleaned up 
> 
> Owner: Anssi
> Status: Anssi still reviewing the patch; decision may be needed on 
> backwards compatibility of get_fields().
>
> #24343  UUID foreign key 
> accessor returns inconsistent type 
> Owner: Marc/Josh/Shai
> Status: Josh working on cleaning up the patch. Review/feedback from Anssi 
> requested.
>
> #24291 
> 
>  Migrations 
> fail with unused swappable model 
> 
> Owner: Markus
> Status: Patch looks good to me; Markus to review & commit tomorrow.
>
> On Monday, February 16, 2015 at 11:12:46 AM UTC-5, Tim Graham wrote:
>>
>> There are still quite a few unresolved issues, so the beta release won't 
>> happen today. I'll send an update at the end of the day with the status of 
>> the remaining issues.
>>
>> On Friday, February 13, 2015 at 1:30:44 PM UTC-5, Markus Holtermann wrote:
>>>
>>> Hey folks,
>>>
>>> I looked into the issues #24225, #24264 and #24282 and have a working 
>>> pull request ready for review: 
>>> https://github.com/django/django/pull/4097
>>>
>>> The essential change in the pull request is the way how the set of 
>>> models that needs to be rerendered is constructed. Instead of naively only 
>>> resolving one level of relations (Only rerender B and C if C changed: A --> 
>>> B --> C) the new approach recursively checks for relational fields 
>>> (forwards and reverse relations (e.g. ForeignKey and ManyToManyRel)) as 
>>> well as inheritance.
>>>
>>> This approach boils down to the following behavior:
>>>
>>> If a completely standalone model (no incoming or outgoing relations and 
>>> no subclasses and only a directed subclass of models.Model) changes, only 
>>> this model will be rerendered, which is the best case scenario. If every 
>>> model is somehow related (directly or through other models) to every other 
>>> model, e.g. through the user model, changing one model from that set will 
>>> require *all* models to be rerendered, which is the worst case scenario 
>>> and results in the similar behavior as 1.7.
>>>
>>> To get that pull request into the 1.8 beta I ask everybody to take a 
>>> look and try it out on their projects. Especially if 1.8 alpha 1 didn't 
>>> work for you.
>>>
>>> Thanks
>>>
>>> /Markus
>>>
>>> On Saturday, December 20, 2014 at 8:40:33 PM UTC+1, Tim Graham wrote:

 As we approach the date for 1.8 alpha, I plan to send a weekly update 
 on the status of release blocking issues.

 We currently have 3 release blockers affecting master. You can use this 
 Trac filter to see them:

 https://code.djangoproject.com/query?status=assigned=new=master=Release+blocker

 You can also see other tickets we are targeting for 1.8 with this 
 filter. This includes some of the remaining large features as well as a 
 couple code reorganizations we want to make closer to when cut the 1.8 
 branch to avoid creating conflicts with the large features that are in 
 progress.

 https://code.djangoproject.com/query?status=assigned=new=~1.8-alpha

 Here is a summary of where we stand with each release blocker:

 #23861 - 
 

Re: status of 1.8 release blockers

2015-02-16 Thread Tim Graham
Here's the status on blockers. Given the work that remains, I don't foresee 
the beta release happening earlier than Wednesday, but the next update of 
this thread will be tomorrow.

#24324  Crashes when project 
path or path to Django install contains a non-ascii character 

Owner: Tim
Status: Patch needs review


#24351    RunPython/RunSQL 
operations in contrib migrations and multi-db routers. 
Owner: Loic
Status: API design decision needed. Time permitting, Loic will write to the 
mailing list on this tomorrow.

#24328  The new 
Options._get_fields() method needs to be cleaned up 

Owner: Anssi
Status: Anssi still reviewing the patch; decision may be needed on 
backwards compatibility of get_fields().

#24343  UUID foreign key 
accessor returns inconsistent type 
Owner: Marc/Josh/Shai
Status: Josh working on cleaning up the patch. Review/feedback from Anssi 
requested.

#24291  Migrations fail with 
unused swappable model 
Owner: Markus
Status: Patch looks good to me; Markus to review & commit tomorrow.

On Monday, February 16, 2015 at 11:12:46 AM UTC-5, Tim Graham wrote:
>
> There are still quite a few unresolved issues, so the beta release won't 
> happen today. I'll send an update at the end of the day with the status of 
> the remaining issues.
>
> On Friday, February 13, 2015 at 1:30:44 PM UTC-5, Markus Holtermann wrote:
>>
>> Hey folks,
>>
>> I looked into the issues #24225, #24264 and #24282 and have a working 
>> pull request ready for review: https://github.com/django/django/pull/4097
>>
>> The essential change in the pull request is the way how the set of models 
>> that needs to be rerendered is constructed. Instead of naively only 
>> resolving one level of relations (Only rerender B and C if C changed: A --> 
>> B --> C) the new approach recursively checks for relational fields 
>> (forwards and reverse relations (e.g. ForeignKey and ManyToManyRel)) as 
>> well as inheritance.
>>
>> This approach boils down to the following behavior:
>>
>> If a completely standalone model (no incoming or outgoing relations and 
>> no subclasses and only a directed subclass of models.Model) changes, only 
>> this model will be rerendered, which is the best case scenario. If every 
>> model is somehow related (directly or through other models) to every other 
>> model, e.g. through the user model, changing one model from that set will 
>> require *all* models to be rerendered, which is the worst case scenario 
>> and results in the similar behavior as 1.7.
>>
>> To get that pull request into the 1.8 beta I ask everybody to take a look 
>> and try it out on their projects. Especially if 1.8 alpha 1 didn't work for 
>> you.
>>
>> Thanks
>>
>> /Markus
>>
>> On Saturday, December 20, 2014 at 8:40:33 PM UTC+1, Tim Graham wrote:
>>>
>>> As we approach the date for 1.8 alpha, I plan to send a weekly update on 
>>> the status of release blocking issues.
>>>
>>> We currently have 3 release blockers affecting master. You can use this 
>>> Trac filter to see them:
>>>
>>> https://code.djangoproject.com/query?status=assigned=new=master=Release+blocker
>>>
>>> You can also see other tickets we are targeting for 1.8 with this 
>>> filter. This includes some of the remaining large features as well as a 
>>> couple code reorganizations we want to make closer to when cut the 1.8 
>>> branch to avoid creating conflicts with the large features that are in 
>>> progress.
>>>
>>> https://code.djangoproject.com/query?status=assigned=new=~1.8-alpha
>>>
>>> Here is a summary of where we stand with each release blocker:
>>>
>>> #23861 - 
>>>  Fields referenced in 
>>> migrations cannot be (re)moved, even if migrations have been squashed 
>>>  Owner: ?
>>> Status: We need someone to investigate a strategy for how we can 
>>> deprecate model fields while keeping them available in historical 
>>> migrations. Any takers? If we cannot complete this, I propose we bump the 
>>> deprecation of IPAddressField until the issue is solved.
>>>
>>> #22340 -  
>>>  Legacy Table Creation 
>>> Methods Not Properly Deprecated 
>>>  Owner: Claude
>>> Status: This issue is being discussed in the thread "Migrations in 
>>> Django 1.7 make unit testing models harder". In short, we likely to need to 
>>> solve the performance issues with migrations before we can proceed with the 
>>> deprecation. If we cannot, we'll likely have to delay 

Re: status of 1.8 release blockers

2015-02-16 Thread Tim Graham
There are still quite a few unresolved issues, so the beta release won't 
happen today. I'll send an update at the end of the day with the status of 
the remaining issues.

On Friday, February 13, 2015 at 1:30:44 PM UTC-5, Markus Holtermann wrote:
>
> Hey folks,
>
> I looked into the issues #24225, #24264 and #24282 and have a working pull 
> request ready for review: https://github.com/django/django/pull/4097
>
> The essential change in the pull request is the way how the set of models 
> that needs to be rerendered is constructed. Instead of naively only 
> resolving one level of relations (Only rerender B and C if C changed: A --> 
> B --> C) the new approach recursively checks for relational fields 
> (forwards and reverse relations (e.g. ForeignKey and ManyToManyRel)) as 
> well as inheritance.
>
> This approach boils down to the following behavior:
>
> If a completely standalone model (no incoming or outgoing relations and no 
> subclasses and only a directed subclass of models.Model) changes, only this 
> model will be rerendered, which is the best case scenario. If every model 
> is somehow related (directly or through other models) to every other model, 
> e.g. through the user model, changing one model from that set will require 
> *all* models to be rerendered, which is the worst case scenario and 
> results in the similar behavior as 1.7.
>
> To get that pull request into the 1.8 beta I ask everybody to take a look 
> and try it out on their projects. Especially if 1.8 alpha 1 didn't work for 
> you.
>
> Thanks
>
> /Markus
>
> On Saturday, December 20, 2014 at 8:40:33 PM UTC+1, Tim Graham wrote:
>>
>> As we approach the date for 1.8 alpha, I plan to send a weekly update on 
>> the status of release blocking issues.
>>
>> We currently have 3 release blockers affecting master. You can use this 
>> Trac filter to see them:
>>
>> https://code.djangoproject.com/query?status=assigned=new=master=Release+blocker
>>
>> You can also see other tickets we are targeting for 1.8 with this filter. 
>> This includes some of the remaining large features as well as a couple code 
>> reorganizations we want to make closer to when cut the 1.8 branch to avoid 
>> creating conflicts with the large features that are in progress.
>>
>> https://code.djangoproject.com/query?status=assigned=new=~1.8-alpha
>>
>> Here is a summary of where we stand with each release blocker:
>>
>> #23861 - 
>>  Fields referenced in 
>> migrations cannot be (re)moved, even if migrations have been squashed 
>>  Owner: ?
>> Status: We need someone to investigate a strategy for how we can 
>> deprecate model fields while keeping them available in historical 
>> migrations. Any takers? If we cannot complete this, I propose we bump the 
>> deprecation of IPAddressField until the issue is solved.
>>
>> #22340 -  
>>  Legacy Table Creation 
>> Methods Not Properly Deprecated 
>>  Owner: Claude
>> Status: This issue is being discussed in the thread "Migrations in Django 
>> 1.7 make unit testing models harder". In short, we likely to need to solve 
>> the performance issues with migrations before we can proceed with the 
>> deprecation. If we cannot, we'll likely have to delay the deprecation.
>>
>> #23271 - Makemessages can 
>> corrupt existing .po files on Windows 
>> 
>> Owner: Ramiro
>> Status: Ramiro said he would have some time to investigate the issue soon.
>>
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/118f8fc8-ec8a-4c8b-a478-b1194f577b7d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: status of 1.8 release blockers

2015-02-13 Thread Markus Holtermann
Hey folks,

I looked into the issues #24225, #24264 and #24282 and have a working pull 
request ready for review: https://github.com/django/django/pull/4097

The essential change in the pull request is the way how the set of models 
that needs to be rerendered is constructed. Instead of naively only 
resolving one level of relations (Only rerender B and C if C changed: A --> 
B --> C) the new approach recursively checks for relational fields 
(forwards and reverse relations (e.g. ForeignKey and ManyToManyRel)) as 
well as inheritance.

This approach boils down to the following behavior:

If a completely standalone model (no incoming or outgoing relations and no 
subclasses and only a directed subclass of models.Model) changes, only this 
model will be rerendered, which is the best case scenario. If every model 
is somehow related (directly or through other models) to every other model, 
e.g. through the user model, changing one model from that set will require 
*all* models to be rerendered, which is the worst case scenario and results 
in the similar behavior as 1.7.

To get that pull request into the 1.8 beta I ask everybody to take a look 
and try it out on their projects. Especially if 1.8 alpha 1 didn't work for 
you.

Thanks

/Markus

On Saturday, December 20, 2014 at 8:40:33 PM UTC+1, Tim Graham wrote:
>
> As we approach the date for 1.8 alpha, I plan to send a weekly update on 
> the status of release blocking issues.
>
> We currently have 3 release blockers affecting master. You can use this 
> Trac filter to see them:
>
> https://code.djangoproject.com/query?status=assigned=new=master=Release+blocker
>
> You can also see other tickets we are targeting for 1.8 with this filter. 
> This includes some of the remaining large features as well as a couple code 
> reorganizations we want to make closer to when cut the 1.8 branch to avoid 
> creating conflicts with the large features that are in progress.
>
> https://code.djangoproject.com/query?status=assigned=new=~1.8-alpha
>
> Here is a summary of where we stand with each release blocker:
>
> #23861 - 
>  Fields referenced in 
> migrations cannot be (re)moved, even if migrations have been squashed 
>  Owner: ?
> Status: We need someone to investigate a strategy for how we can deprecate 
> model fields while keeping them available in historical migrations. Any 
> takers? If we cannot complete this, I propose we bump the deprecation of 
> IPAddressField until the issue is solved.
>
> #22340 -  
>  Legacy Table Creation 
> Methods Not Properly Deprecated 
>  Owner: Claude
> Status: This issue is being discussed in the thread "Migrations in Django 
> 1.7 make unit testing models harder". In short, we likely to need to solve 
> the performance issues with migrations before we can proceed with the 
> deprecation. If we cannot, we'll likely have to delay the deprecation.
>
> #23271 - Makemessages can 
> corrupt existing .po files on Windows 
> 
> Owner: Ramiro
> Status: Ramiro said he would have some time to investigate the issue soon.
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/347cdd1d-bb4e-406e-bc85-f75f9c99ead5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: status of 1.8 release blockers

2015-02-12 Thread Markus Holtermann
Hey Tim,

Thanks for the update. Could you check if #24282 is fixed by my PR as well and 
assign it to me in case it is. The error message looks familiar to the one I 
commented on the PR. Thanks.

/Markus

On February 13, 2015 2:33:38 AM GMT+01:00, Tim Graham  
wrote:
>Status of release blockers:
>
>#24320  Unable to
>serialize 
>UUIDField when running dumpdata with JSON format 
>
>Status: I wrote a failing test and will try to write a patch tomorrow
>if no 
>one else takes a look first.
>
>#24289  Is usage of 
>many_to_one and one_to_many terms confusing for relation flags? 
>
>Status: We are waiting for feedback/confirmation from Anssi and Russ
>about 
>the direction to take here.
>
>#24225  KeyError when 
>migrating in 1.8a1/master@728b6fd (does not occur in 1.7.3) 
>
>#24264  foreign key
>constraint 
>error migrating integer pk to CharField 
>
>Status: Markus has a patch which addresses both issues. It's in good
>shape 
>and should be ready for commit soon.
>
>#24282  Cannot Modify
>Foreign 
>Keys Within Data Migrations
>
>Status: This is awaiting a test case to reproduce the issue (I'll 
>investigate tomorrow if no one else does).
>
>Here is the filter for 1.8 release blockers as well as issues tagged
>1.8 
>beta or 1.8 and thus are on my radar to make a decision on in the next 
>couple days:
>https://code.djangoproject.com/query?status=assigned=new=1.8alpha1=Release+blocker=~1.8-beta=assigned=new=~1.8=assigned=new=id=summary=status=owner=type=component=changetime=1=changetime
>
>On Wednesday, February 4, 2015 at 9:45:33 AM UTC-5, Tim Graham wrote:
>>
>> Reminder that the 1.8 beta release is scheduled for twelve days from
>now: 
>> Monday, February 16. 
>>
>> Please check this filter for remaining blockers for beta:
>>
>>
>>
>https://code.djangoproject.com/query?status=assigned=new=1.8alpha1=Release+blocker=assigned=new=~1.8-beta=id=summary=status=owner=type=component=changetime=1=changetime
>>
>> I'll follow up next week to ensure we have owners for any issues that
>
>> remain after the weekend.
>>
>> On Thursday, January 15, 2015 at 8:30:04 PM UTC-5, Tim Graham wrote:
>>>
>>> I think master is stabilizing and the number of unsolved regressions
>
>>> should be ~0 by tomorrow. I'd like to release the alpha around 2100
>UTC 
>>> tomorrow +/- ~4 hours depending on how things go with the remaining
>issues. 
>>> Let me know if there is anything you think needs to be in the alpha
>that 
>>> wouldn't meet this deadline.
>>>
>>> On Tuesday, January 13, 2015 at 1:50:26 AM UTC-5, Tino de Bruijn
>wrote:

 Congratulations! Looks like you've steadily moved it through.

 Tino

 On Tue, Jan 13, 2015 at 3:25 AM, Tim Graham 
>wrote:

> We did it -- all features are in or out for alpha. Please consider
>
> master frozen for new features until we cut the stable/1.8.x
>branch later 
> this week. Feel free to commit code cleanups and/or bug fixes
>until then.
>
>
> On Friday, January 9, 2015 at 1:14:02 PM UTC-5, Tim Graham wrote:
>>
>> Here is the fifth update with several days to go until alpha. I 
>> believe we are on track for a feature freeze at the end of day on
>Monday. 
>> Let's see how things go, but I'd like to cut the stable/1.8.x
>branch and 
>> issue the alpha release by the following Friday (a week from
>today).
>>
>> New blockers:
>>
>> #24075  - Can't
>migrate 
>> contenttypes and auth to zero 
>> 
>> Owner: Simon
>> Status: This is an existing issue on 1.7, but addressing it seems
>to 
>> require (or at least, would be a lot easier) with the proposed
>new feature 
>> of adding a "plan" argument to the post_migrate() signal. There
>is a patch 
>> in the works.
>>
>> Resolved since last time:
>>
>> #23861 - 
>>  Fields referenced
>in 
>> migrations cannot be (re)moved, even if migrations have been
>squashed 
>> 
>> Owner: Tim
>> Now: I polished and committed the patch for this.
>> Last time: I committed a patch for the second ticket and will
>polish 
>> the patch for the first issue.
>>
>> Most of the issues tagged "1.8-alpha" have been completed or
>deferred. 
>> The two main ones that remain are "Case/When expressions" and
>"Allowing 
>> expressions to be used in order_by 

Re: status of 1.8 release blockers

2015-02-12 Thread Tim Graham
Status of release blockers:

#24320  Unable to serialize 
UUIDField when running dumpdata with JSON format 

Status: I wrote a failing test and will try to write a patch tomorrow if no 
one else takes a look first.

#24289  Is usage of 
many_to_one and one_to_many terms confusing for relation flags? 

Status: We are waiting for feedback/confirmation from Anssi and Russ about 
the direction to take here.

#24225  KeyError when 
migrating in 1.8a1/master@728b6fd (does not occur in 1.7.3) 

#24264  foreign key constraint 
error migrating integer pk to CharField 

Status: Markus has a patch which addresses both issues. It's in good shape 
and should be ready for commit soon.

#24282  Cannot Modify Foreign 
Keys Within Data Migrations 
Status: This is awaiting a test case to reproduce the issue (I'll 
investigate tomorrow if no one else does).

Here is the filter for 1.8 release blockers as well as issues tagged 1.8 
beta or 1.8 and thus are on my radar to make a decision on in the next 
couple days:
https://code.djangoproject.com/query?status=assigned=new=1.8alpha1=Release+blocker=~1.8-beta=assigned=new=~1.8=assigned=new=id=summary=status=owner=type=component=changetime=1=changetime

On Wednesday, February 4, 2015 at 9:45:33 AM UTC-5, Tim Graham wrote:
>
> Reminder that the 1.8 beta release is scheduled for twelve days from now: 
> Monday, February 16. 
>
> Please check this filter for remaining blockers for beta:
>
>
> https://code.djangoproject.com/query?status=assigned=new=1.8alpha1=Release+blocker=assigned=new=~1.8-beta=id=summary=status=owner=type=component=changetime=1=changetime
>
> I'll follow up next week to ensure we have owners for any issues that 
> remain after the weekend.
>
> On Thursday, January 15, 2015 at 8:30:04 PM UTC-5, Tim Graham wrote:
>>
>> I think master is stabilizing and the number of unsolved regressions 
>> should be ~0 by tomorrow. I'd like to release the alpha around 2100 UTC 
>> tomorrow +/- ~4 hours depending on how things go with the remaining issues. 
>> Let me know if there is anything you think needs to be in the alpha that 
>> wouldn't meet this deadline.
>>
>> On Tuesday, January 13, 2015 at 1:50:26 AM UTC-5, Tino de Bruijn wrote:
>>>
>>> Congratulations! Looks like you've steadily moved it through.
>>>
>>> Tino
>>>
>>> On Tue, Jan 13, 2015 at 3:25 AM, Tim Graham  wrote:
>>>
 We did it -- all features are in or out for alpha. Please consider 
 master frozen for new features until we cut the stable/1.8.x branch later 
 this week. Feel free to commit code cleanups and/or bug fixes until then.


 On Friday, January 9, 2015 at 1:14:02 PM UTC-5, Tim Graham wrote:
>
> Here is the fifth update with several days to go until alpha. I 
> believe we are on track for a feature freeze at the end of day on Monday. 
> Let's see how things go, but I'd like to cut the stable/1.8.x branch and 
> issue the alpha release by the following Friday (a week from today).
>
> New blockers:
>
> #24075  - Can't migrate 
> contenttypes and auth to zero 
> 
> Owner: Simon
> Status: This is an existing issue on 1.7, but addressing it seems to 
> require (or at least, would be a lot easier) with the proposed new 
> feature 
> of adding a "plan" argument to the post_migrate() signal. There is a 
> patch 
> in the works.
>
> Resolved since last time:
>
> #23861 - 
>  Fields referenced in 
> migrations cannot be (re)moved, even if migrations have been squashed 
> 
> Owner: Tim
> Now: I polished and committed the patch for this.
> Last time: I committed a patch for the second ticket and will polish 
> the patch for the first issue.
>
> Most of the issues tagged "1.8-alpha" have been completed or deferred. 
> The two main ones that remain are "Case/When expressions" and "Allowing 
> expressions to be used in order_by queryset method." Depending on what 
> progress is made over the weekend on these issues, they may or may not 
> make 
> it into 1.8.
> https://code.djangoproject.com/query?status=assigned;
> status=new=~1.8-alpha
>
> On Saturday, January 3, 2015 at 1:19:25 PM UTC-5, jdunck wrote:
>>
>> Thank you, Tim, for shepherding this.
>> On Jan 3, 2015 8:09 AM, "Tim Graham" 

Re: status of 1.8 release blockers

2015-02-04 Thread Tim Graham
Reminder that the 1.8 beta release is scheduled for twelve days from now: 
Monday, February 16. 

Please check this filter for remaining blockers for beta:

https://code.djangoproject.com/query?status=assigned=new=1.8alpha1=Release+blocker=assigned=new=~1.8-beta=id=summary=status=owner=type=component=changetime=1=changetime

I'll follow up next week to ensure we have owners for any issues that 
remain after the weekend.

On Thursday, January 15, 2015 at 8:30:04 PM UTC-5, Tim Graham wrote:
>
> I think master is stabilizing and the number of unsolved regressions 
> should be ~0 by tomorrow. I'd like to release the alpha around 2100 UTC 
> tomorrow +/- ~4 hours depending on how things go with the remaining issues. 
> Let me know if there is anything you think needs to be in the alpha that 
> wouldn't meet this deadline.
>
> On Tuesday, January 13, 2015 at 1:50:26 AM UTC-5, Tino de Bruijn wrote:
>>
>> Congratulations! Looks like you've steadily moved it through.
>>
>> Tino
>>
>> On Tue, Jan 13, 2015 at 3:25 AM, Tim Graham  wrote:
>>
>>> We did it -- all features are in or out for alpha. Please consider 
>>> master frozen for new features until we cut the stable/1.8.x branch later 
>>> this week. Feel free to commit code cleanups and/or bug fixes until then.
>>>
>>>
>>> On Friday, January 9, 2015 at 1:14:02 PM UTC-5, Tim Graham wrote:

 Here is the fifth update with several days to go until alpha. I believe 
 we are on track for a feature freeze at the end of day on Monday. Let's 
 see 
 how things go, but I'd like to cut the stable/1.8.x branch and issue the 
 alpha release by the following Friday (a week from today).

 New blockers:

 #24075  - Can't migrate 
 contenttypes and auth to zero 
 
 Owner: Simon
 Status: This is an existing issue on 1.7, but addressing it seems to 
 require (or at least, would be a lot easier) with the proposed new feature 
 of adding a "plan" argument to the post_migrate() signal. There is a patch 
 in the works.

 Resolved since last time:

 #23861 - 
  Fields referenced in 
 migrations cannot be (re)moved, even if migrations have been squashed 
 
 Owner: Tim
 Now: I polished and committed the patch for this.
 Last time: I committed a patch for the second ticket and will polish 
 the patch for the first issue.

 Most of the issues tagged "1.8-alpha" have been completed or deferred. 
 The two main ones that remain are "Case/When expressions" and "Allowing 
 expressions to be used in order_by queryset method." Depending on what 
 progress is made over the weekend on these issues, they may or may not 
 make 
 it into 1.8.
 https://code.djangoproject.com/query?status=assigned;
 status=new=~1.8-alpha

 On Saturday, January 3, 2015 at 1:19:25 PM UTC-5, jdunck wrote:
>
> Thank you, Tim, for shepherding this.
> On Jan 3, 2015 8:09 AM, "Tim Graham"  wrote:
>
>> Here is the fourth update with a week to go until alpha. At this 
>> time, I am thinking we'll have the feature freeze on Monday, January 12 
>> as 
>> planned, but perhaps issue the actual alpha release a couple days later 
>> just to give some time for some extra polish in case any large patches 
>> are 
>> committed next weekend.
>>
>> #23861 - 
>>  Fields referenced in 
>> migrations cannot be (re)moved, even if migrations have been squashed 
>> 
>> #23891  - Revise 
>> deprecation / removal timeline for IPAddressField 
>>  (resolved)
>> Owner: Tim
>> Now: I committed a patch for the second ticket and will polish the 
>> patch for the first issue.
>> Last time: I've implemented the system check solution I proposed and 
>> am waiting for review and/or concerns with this approach.
>>
>> After completing the issue above, I'll prioritize any issues here:
>> https://code.djangoproject.com/query?status=assigned;
>> status=new=~1.8-alpha
>>
>> Resolved since last time:
>>
>> #22340 -  
>>  Legacy Table Creation 
>> Methods Not Properly Deprecated 
>> 
>> Owner: Tim
>> Now: Resolved this by removing the deprecation as discussed in the 
>> ticket.
>> Last time: I took a closer look at this and don't think we need to do 
>> this deprecation at all as it doesn't seem to offer any benefits. See 
>> the 
>> ticket for details.
>>
>> 

Re: status of 1.8 release blockers

2015-01-15 Thread Tim Graham
I think master is stabilizing and the number of unsolved regressions should 
be ~0 by tomorrow. I'd like to release the alpha around 2100 UTC tomorrow 
+/- ~4 hours depending on how things go with the remaining issues. Let me 
know if there is anything you think needs to be in the alpha that wouldn't 
meet this deadline.

On Tuesday, January 13, 2015 at 1:50:26 AM UTC-5, Tino de Bruijn wrote:
>
> Congratulations! Looks like you've steadily moved it through.
>
> Tino
>
> On Tue, Jan 13, 2015 at 3:25 AM, Tim Graham  > wrote:
>
>> We did it -- all features are in or out for alpha. Please consider master 
>> frozen for new features until we cut the stable/1.8.x branch later this 
>> week. Feel free to commit code cleanups and/or bug fixes until then.
>>
>>
>> On Friday, January 9, 2015 at 1:14:02 PM UTC-5, Tim Graham wrote:
>>>
>>> Here is the fifth update with several days to go until alpha. I believe 
>>> we are on track for a feature freeze at the end of day on Monday. Let's see 
>>> how things go, but I'd like to cut the stable/1.8.x branch and issue the 
>>> alpha release by the following Friday (a week from today).
>>>
>>> New blockers:
>>>
>>> #24075  - Can't migrate 
>>> contenttypes and auth to zero 
>>> 
>>> Owner: Simon
>>> Status: This is an existing issue on 1.7, but addressing it seems to 
>>> require (or at least, would be a lot easier) with the proposed new feature 
>>> of adding a "plan" argument to the post_migrate() signal. There is a patch 
>>> in the works.
>>>
>>> Resolved since last time:
>>>
>>> #23861 - 
>>>  Fields referenced in 
>>> migrations cannot be (re)moved, even if migrations have been squashed 
>>> 
>>> Owner: Tim
>>> Now: I polished and committed the patch for this.
>>> Last time: I committed a patch for the second ticket and will polish the 
>>> patch for the first issue.
>>>
>>> Most of the issues tagged "1.8-alpha" have been completed or deferred. 
>>> The two main ones that remain are "Case/When expressions" and "Allowing 
>>> expressions to be used in order_by queryset method." Depending on what 
>>> progress is made over the weekend on these issues, they may or may not make 
>>> it into 1.8.
>>> https://code.djangoproject.com/query?status=assigned;
>>> status=new=~1.8-alpha
>>>
>>> On Saturday, January 3, 2015 at 1:19:25 PM UTC-5, jdunck wrote:

 Thank you, Tim, for shepherding this.
 On Jan 3, 2015 8:09 AM, "Tim Graham"  wrote:

> Here is the fourth update with a week to go until alpha. At this time, 
> I am thinking we'll have the feature freeze on Monday, January 12 as 
> planned, but perhaps issue the actual alpha release a couple days later 
> just to give some time for some extra polish in case any large patches 
> are 
> committed next weekend.
>
> #23861 - 
>  Fields referenced in 
> migrations cannot be (re)moved, even if migrations have been squashed 
> 
> #23891  - Revise 
> deprecation / removal timeline for IPAddressField 
>  (resolved)
> Owner: Tim
> Now: I committed a patch for the second ticket and will polish the 
> patch for the first issue.
> Last time: I've implemented the system check solution I proposed and 
> am waiting for review and/or concerns with this approach.
>
> After completing the issue above, I'll prioritize any issues here:
> https://code.djangoproject.com/query?status=assigned;
> status=new=~1.8-alpha
>
> Resolved since last time:
>
> #22340 -  
>  Legacy Table Creation 
> Methods Not Properly Deprecated 
> 
> Owner: Tim
> Now: Resolved this by removing the deprecation as discussed in the 
> ticket.
> Last time: I took a closer look at this and don't think we need to do 
> this deprecation at all as it doesn't seem to offer any benefits. See the 
> ticket for details.
>
> #23745 - Migrations migrate is slow 
> 
> Owner: Claude/Markus
> Now: Patch committed; thanks to Markus and Claude.
> Last time: I committed the test that Markus wrote and Claude 
> incorporated a fix from Markus so the branch appears about ready for 
> merge. 
> Markus will give it another review.
>
> -- 
> 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 

Re: status of 1.8 release blockers

2015-01-12 Thread Tino de Bruijn
Congratulations! Looks like you've steadily moved it through.

Tino

On Tue, Jan 13, 2015 at 3:25 AM, Tim Graham  wrote:

> We did it -- all features are in or out for alpha. Please consider master
> frozen for new features until we cut the stable/1.8.x branch later this
> week. Feel free to commit code cleanups and/or bug fixes until then.
>
>
> On Friday, January 9, 2015 at 1:14:02 PM UTC-5, Tim Graham wrote:
>>
>> Here is the fifth update with several days to go until alpha. I believe
>> we are on track for a feature freeze at the end of day on Monday. Let's see
>> how things go, but I'd like to cut the stable/1.8.x branch and issue the
>> alpha release by the following Friday (a week from today).
>>
>> New blockers:
>>
>> #24075  - Can't migrate
>> contenttypes and auth to zero
>> 
>> Owner: Simon
>> Status: This is an existing issue on 1.7, but addressing it seems to
>> require (or at least, would be a lot easier) with the proposed new feature
>> of adding a "plan" argument to the post_migrate() signal. There is a patch
>> in the works.
>>
>> Resolved since last time:
>>
>> #23861 -
>>  Fields referenced in
>> migrations cannot be (re)moved, even if migrations have been squashed
>> 
>> Owner: Tim
>> Now: I polished and committed the patch for this.
>> Last time: I committed a patch for the second ticket and will polish the
>> patch for the first issue.
>>
>> Most of the issues tagged "1.8-alpha" have been completed or deferred.
>> The two main ones that remain are "Case/When expressions" and "Allowing
>> expressions to be used in order_by queryset method." Depending on what
>> progress is made over the weekend on these issues, they may or may not make
>> it into 1.8.
>> https://code.djangoproject.com/query?status=assigned;
>> status=new=~1.8-alpha
>>
>> On Saturday, January 3, 2015 at 1:19:25 PM UTC-5, jdunck wrote:
>>>
>>> Thank you, Tim, for shepherding this.
>>> On Jan 3, 2015 8:09 AM, "Tim Graham"  wrote:
>>>
 Here is the fourth update with a week to go until alpha. At this time,
 I am thinking we'll have the feature freeze on Monday, January 12 as
 planned, but perhaps issue the actual alpha release a couple days later
 just to give some time for some extra polish in case any large patches are
 committed next weekend.

 #23861 -
  Fields referenced in
 migrations cannot be (re)moved, even if migrations have been squashed
 
 #23891  - Revise
 deprecation / removal timeline for IPAddressField
  (resolved)
 Owner: Tim
 Now: I committed a patch for the second ticket and will polish the
 patch for the first issue.
 Last time: I've implemented the system check solution I proposed and am
 waiting for review and/or concerns with this approach.

 After completing the issue above, I'll prioritize any issues here:
 https://code.djangoproject.com/query?status=assigned;
 status=new=~1.8-alpha

 Resolved since last time:

 #22340 -
  Legacy Table Creation
 Methods Not Properly Deprecated
 
 Owner: Tim
 Now: Resolved this by removing the deprecation as discussed in the
 ticket.
 Last time: I took a closer look at this and don't think we need to do
 this deprecation at all as it doesn't seem to offer any benefits. See the
 ticket for details.

 #23745 - Migrations migrate is slow
 
 Owner: Claude/Markus
 Now: Patch committed; thanks to Markus and Claude.
 Last time: I committed the test that Markus wrote and Claude
 incorporated a fix from Markus so the branch appears about ready for merge.
 Markus will give it another review.

 --
 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-develop...@googlegroups.com.
 To post to this group, send email to django-d...@googlegroups.com.
 Visit this group at http://groups.google.com/group/django-developers.
 To view this discussion on the web visit https://groups.google.com/d/
 msgid/django-developers/b196f095-530c-45ec-9b21-
 82fcd1c06ed8%40googlegroups.com
 
 .
 For more options, visit 

Re: status of 1.8 release blockers

2015-01-12 Thread Tim Graham
We did it -- all features are in or out for alpha. Please consider master 
frozen for new features until we cut the stable/1.8.x branch later this 
week. Feel free to commit code cleanups and/or bug fixes until then.

On Friday, January 9, 2015 at 1:14:02 PM UTC-5, Tim Graham wrote:
>
> Here is the fifth update with several days to go until alpha. I believe we 
> are on track for a feature freeze at the end of day on Monday. Let's see 
> how things go, but I'd like to cut the stable/1.8.x branch and issue the 
> alpha release by the following Friday (a week from today).
>
> New blockers:
>
> #24075  - Can't migrate 
> contenttypes and auth to zero 
> 
> Owner: Simon
> Status: This is an existing issue on 1.7, but addressing it seems to 
> require (or at least, would be a lot easier) with the proposed new feature 
> of adding a "plan" argument to the post_migrate() signal. There is a patch 
> in the works.
>
> Resolved since last time:
>
> #23861 - 
>  Fields referenced in 
> migrations cannot be (re)moved, even if migrations have been squashed 
> 
> Owner: Tim
> Now: I polished and committed the patch for this.
> Last time: I committed a patch for the second ticket and will polish the 
> patch for the first issue.
>
> Most of the issues tagged "1.8-alpha" have been completed or deferred. The 
> two main ones that remain are "Case/When expressions" and "Allowing 
> expressions to be used in order_by queryset method." Depending on what 
> progress is made over the weekend on these issues, they may or may not make 
> it into 1.8.
>
> https://code.djangoproject.com/query?status=assigned=new=~1.8-alpha
>
> On Saturday, January 3, 2015 at 1:19:25 PM UTC-5, jdunck wrote:
>>
>> Thank you, Tim, for shepherding this.
>> On Jan 3, 2015 8:09 AM, "Tim Graham"  wrote:
>>
>>> Here is the fourth update with a week to go until alpha. At this time, I 
>>> am thinking we'll have the feature freeze on Monday, January 12 as planned, 
>>> but perhaps issue the actual alpha release a couple days later just to give 
>>> some time for some extra polish in case any large patches are committed 
>>> next weekend.
>>>
>>> #23861 - 
>>>  Fields referenced in 
>>> migrations cannot be (re)moved, even if migrations have been squashed 
>>> 
>>> #23891  - Revise 
>>> deprecation / removal timeline for IPAddressField 
>>>  (resolved)
>>> Owner: Tim
>>> Now: I committed a patch for the second ticket and will polish the patch 
>>> for the first issue.
>>> Last time: I've implemented the system check solution I proposed and am 
>>> waiting for review and/or concerns with this approach.
>>>
>>> After completing the issue above, I'll prioritize any issues here:
>>>
>>> https://code.djangoproject.com/query?status=assigned=new=~1.8-alpha
>>>
>>> Resolved since last time:
>>>
>>> #22340 -  
>>>  Legacy Table Creation 
>>> Methods Not Properly Deprecated 
>>> 
>>> Owner: Tim
>>> Now: Resolved this by removing the deprecation as discussed in the 
>>> ticket.
>>> Last time: I took a closer look at this and don't think we need to do 
>>> this deprecation at all as it doesn't seem to offer any benefits. See the 
>>> ticket for details.
>>>
>>> #23745 - Migrations migrate is slow 
>>> 
>>> Owner: Claude/Markus
>>> Now: Patch committed; thanks to Markus and Claude.
>>> Last time: I committed the test that Markus wrote and Claude 
>>> incorporated a fix from Markus so the branch appears about ready for merge. 
>>> Markus will give it another review.
>>>
>>> -- 
>>> 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-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/b196f095-530c-45ec-9b21-82fcd1c06ed8%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, 

Re: status of 1.8 release blockers

2015-01-09 Thread Tim Graham
Here is the fifth update with several days to go until alpha. I believe we 
are on track for a feature freeze at the end of day on Monday. Let's see 
how things go, but I'd like to cut the stable/1.8.x branch and issue the 
alpha release by the following Friday (a week from today).

New blockers:

#24075  - Can't migrate 
contenttypes and auth to zero 
Owner: Simon
Status: This is an existing issue on 1.7, but addressing it seems to 
require (or at least, would be a lot easier) with the proposed new feature 
of adding a "plan" argument to the post_migrate() signal. There is a patch 
in the works.

Resolved since last time:

#23861 - 
 Fields referenced in 
migrations cannot be (re)moved, even if migrations have been squashed 

Owner: Tim
Now: I polished and committed the patch for this.
Last time: I committed a patch for the second ticket and will polish the 
patch for the first issue.

Most of the issues tagged "1.8-alpha" have been completed or deferred. The 
two main ones that remain are "Case/When expressions" and "Allowing 
expressions to be used in order_by queryset method." Depending on what 
progress is made over the weekend on these issues, they may or may not make 
it into 1.8.
https://code.djangoproject.com/query?status=assigned=new=~1.8-alpha

On Saturday, January 3, 2015 at 1:19:25 PM UTC-5, jdunck wrote:
>
> Thank you, Tim, for shepherding this.
> On Jan 3, 2015 8:09 AM, "Tim Graham"  
> wrote:
>
>> Here is the fourth update with a week to go until alpha. At this time, I 
>> am thinking we'll have the feature freeze on Monday, January 12 as planned, 
>> but perhaps issue the actual alpha release a couple days later just to give 
>> some time for some extra polish in case any large patches are committed 
>> next weekend.
>>
>> #23861 - 
>>  Fields referenced in 
>> migrations cannot be (re)moved, even if migrations have been squashed 
>> 
>> #23891  - Revise 
>> deprecation / removal timeline for IPAddressField 
>>  (resolved)
>> Owner: Tim
>> Now: I committed a patch for the second ticket and will polish the patch 
>> for the first issue.
>> Last time: I've implemented the system check solution I proposed and am 
>> waiting for review and/or concerns with this approach.
>>
>> After completing the issue above, I'll prioritize any issues here:
>>
>> https://code.djangoproject.com/query?status=assigned=new=~1.8-alpha
>>
>> Resolved since last time:
>>
>> #22340 -  
>>  Legacy Table Creation 
>> Methods Not Properly Deprecated 
>> 
>> Owner: Tim
>> Now: Resolved this by removing the deprecation as discussed in the ticket.
>> Last time: I took a closer look at this and don't think we need to do 
>> this deprecation at all as it doesn't seem to offer any benefits. See the 
>> ticket for details.
>>
>> #23745 - Migrations migrate is slow 
>> 
>> Owner: Claude/Markus
>> Now: Patch committed; thanks to Markus and Claude.
>> Last time: I committed the test that Markus wrote and Claude incorporated 
>> a fix from Markus so the branch appears about ready for merge. Markus will 
>> give it another review.
>>
>> -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/b196f095-530c-45ec-9b21-82fcd1c06ed8%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5680073d-8a2e-4370-945a-c18d846e1e25%40googlegroups.com.
For more options, visit 

Re: status of 1.8 release blockers

2015-01-03 Thread Jeremy Dunck
Thank you, Tim, for shepherding this.
On Jan 3, 2015 8:09 AM, "Tim Graham"  wrote:

> Here is the fourth update with a week to go until alpha. At this time, I
> am thinking we'll have the feature freeze on Monday, January 12 as planned,
> but perhaps issue the actual alpha release a couple days later just to give
> some time for some extra polish in case any large patches are committed
> next weekend.
>
> #23861 -
>  Fields referenced in
> migrations cannot be (re)moved, even if migrations have been squashed
> 
> #23891  - Revise deprecation
> / removal timeline for IPAddressField
>  (resolved)
> Owner: Tim
> Now: I committed a patch for the second ticket and will polish the patch
> for the first issue.
> Last time: I've implemented the system check solution I proposed and am
> waiting for review and/or concerns with this approach.
>
> After completing the issue above, I'll prioritize any issues here:
>
> https://code.djangoproject.com/query?status=assigned=new=~1.8-alpha
>
> Resolved since last time:
>
> #22340 -
>  Legacy Table Creation
> Methods Not Properly Deprecated
> 
> Owner: Tim
> Now: Resolved this by removing the deprecation as discussed in the ticket.
> Last time: I took a closer look at this and don't think we need to do this
> deprecation at all as it doesn't seem to offer any benefits. See the ticket
> for details.
>
> #23745 - Migrations migrate is slow
> 
> Owner: Claude/Markus
> Now: Patch committed; thanks to Markus and Claude.
> Last time: I committed the test that Markus wrote and Claude incorporated
> a fix from Markus so the branch appears about ready for merge. Markus will
> give it another review.
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/b196f095-530c-45ec-9b21-82fcd1c06ed8%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAM0i3f5KyOKN_z_OExai9ExkkThPQL3570XW0w6E6EJsO1MNQA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: status of 1.8 release blockers

2015-01-03 Thread Tim Graham
Here is the fourth update with a week to go until alpha. At this time, I am 
thinking we'll have the feature freeze on Monday, January 12 as planned, 
but perhaps issue the actual alpha release a couple days later just to give 
some time for some extra polish in case any large patches are committed 
next weekend.

#23861 - 
 Fields referenced in 
migrations cannot be (re)moved, even if migrations have been squashed 

#23891  - Revise deprecation / 
removal timeline for IPAddressField 
 (resolved)
Owner: Tim
Now: I committed a patch for the second ticket and will polish the patch 
for the first issue.
Last time: I've implemented the system check solution I proposed and am 
waiting for review and/or concerns with this approach.

After completing the issue above, I'll prioritize any issues here:
https://code.djangoproject.com/query?status=assigned=new=~1.8-alpha

Resolved since last time:

#22340 -  
 Legacy Table Creation Methods 
Not Properly Deprecated 
Owner: Tim
Now: Resolved this by removing the deprecation as discussed in the ticket.
Last time: I took a closer look at this and don't think we need to do this 
deprecation at all as it doesn't seem to offer any benefits. See the ticket 
for details.

#23745 - Migrations migrate is slow 

Owner: Claude/Markus
Now: Patch committed; thanks to Markus and Claude.
Last time: I committed the test that Markus wrote and Claude incorporated a 
fix from Markus so the branch appears about ready for merge. Markus will 
give it another review.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b196f095-530c-45ec-9b21-82fcd1c06ed8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: status of 1.8 release blockers

2014-12-30 Thread Tim Graham
Here is the third update with a week and a half to go until alpha (I 
incorrectly said in the last update a couple days ago that we have 3 weeks 
left!):

#23861 - 
 Fields referenced in 
migrations cannot be (re)moved, even if migrations have been squashed 

#23891  - Revise deprecation / 
removal timeline for IPAddressField 

Owner: Tim
Now: I've implemented the system check solution I proposed and am waiting 
for review and/or concerns with this approach.
Last time: On ticket #23891 I proposed the idea of moving model field 
deprecation warnings to the system check framework. I am waiting for 
feedback on this approach before investing further.

#22340 -  
 Legacy Table Creation Methods 
Not Properly Deprecated 
Owner: Tim
Now: I took a closer look at this and don't think we need to do this 
deprecation at all as it doesn't seem to offer any benefits. See the ticket 
for details.
Last time: I think the performance concerns are no longer a blocker to 
resolving this ticket (see the mailing list thread for details). I did 
research on the remaining work needed and left a comment on the ticket. I 
will work on the implementation next week if no one else picks it up.

#23745 - Migrations migrate is slow 
 (new)
Owner: Claude/Markus
Now: I committed the test that Markus wrote and Claude incorporated a fix 
from Markus so the branch appears about ready for merge. Markus will give 
it another review.
Last time: Patch seems to need improvement so it doesn't cause a regression 
with swappable models.

#23271 - Makemessages can 
corrupt existing .po files on Windows 

Owner: Ramiro
Now: Resolved by Ramio
Last time: no update

On Tuesday, December 30, 2014 7:49:59 AM UTC-5, Markus Holtermann wrote:
>
> On Monday, December 29, 2014 10:40:06 AM UTC+1, Claude Paroz wrote:
>>
>> On Saturday, December 27, 2014 4:46:52 PM UTC+1, Tim Graham wrote:
>>>
>>> #23745 - Migrations migrate is slow 
>>>  (new)
>>> Owner: Claude
>>> Status: Patch seems to need improvement so it doesn't cause a regression 
>>> with swappable models.
>>>
>>
>> Sorry, but I'm afraid you should remove my name as the owner at this 
>> stage.
>>
>
> I took a look at the PR and added a test case that passes on stable/1.7.x 
> and master. If the PR is applied as-is it fails: 
> https://github.com/MarkusH/django/commit/9bc0d669e1fec3d9b3886ecf0c44bbf77b25ef6d
>  
> . But I'd like to get a few more eyes on the test so we can make sure it 
> correctly represents the issue described in the ticket.
>
> I furthermore tried to fix the issue with the patch in 
> https://github.com/MarkusH/django/commit/9651ceebfe5a27bf4a095098e92454766480d931
>  
> . Assuming the test above is correct, this might be a way to solve the 
> issue.
>
> /Markus
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ce2b5e72-e21c-4ce8-a348-e6486c979471%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: status of 1.8 release blockers

2014-12-30 Thread Markus Holtermann
On Monday, December 29, 2014 10:40:06 AM UTC+1, Claude Paroz wrote:
>
> On Saturday, December 27, 2014 4:46:52 PM UTC+1, Tim Graham wrote:
>>
>> #23745 - Migrations migrate is slow 
>>  (new)
>> Owner: Claude
>> Status: Patch seems to need improvement so it doesn't cause a regression 
>> with swappable models.
>>
>
> Sorry, but I'm afraid you should remove my name as the owner at this stage.
>

I took a look at the PR and added a test case that passes on stable/1.7.x 
and master. If the PR is applied as-is it fails: 
https://github.com/MarkusH/django/commit/9bc0d669e1fec3d9b3886ecf0c44bbf77b25ef6d
 
. But I'd like to get a few more eyes on the test so we can make sure it 
correctly represents the issue described in the ticket.

I furthermore tried to fix the issue with the patch 
in 
https://github.com/MarkusH/django/commit/9651ceebfe5a27bf4a095098e92454766480d931
 
. Assuming the test above is correct, this might be a way to solve the 
issue.

/Markus

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/48518bb0-bf86-4485-adae-4ce3cded100e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: status of 1.8 release blockers

2014-12-29 Thread Claude Paroz
On Saturday, December 27, 2014 4:46:52 PM UTC+1, Tim Graham wrote:
>
> #23745 - Migrations migrate is slow 
>  (new)
> Owner: Claude
> Status: Patch seems to need improvement so it doesn't cause a regression 
> with swappable models.
>

Sorry, but I'm afraid you should remove my name as the owner at this stage.

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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3a4293ce-4125-4313-b5ec-434c1f066cd9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: status of 1.8 release blockers

2014-12-27 Thread Tim Graham
Here is the second update with three weeks to go until alpha:

#23861 - 
 Fields referenced in 
migrations cannot be (re)moved, even if migrations have been squashed 

#23891  - Revise deprecation / 
removal timeline for IPAddressField 

Owner: ?
This week: On ticket #23891 I proposed the idea of moving model field 
deprecation warnings to the system check framework. I am waiting for 
feedback on this approach before investing further.
Last week's status: We need someone to investigate a strategy for how we 
can deprecate model fields while keeping them available in historical 
migrations. Any takers? If we cannot complete this, I propose we bump the 
deprecation of IPAddressField until the issue is solved.

#22340 -  
 Legacy Table Creation Methods 
Not Properly Deprecated 
Owner: ?
This week: I think the performance concerns are no longer a blocker to 
resolving this ticket (see the mailing list thread for details). I did 
research on the remaining work needed and left a comment on the ticket. I 
will work on the implementation next week if no one else picks it up.
Last week's status: This issue is being discussed in the thread "Migrations 
in Django 1.7 make unit testing models harder". In short, we likely to need 
to solve the performance issues with migrations before we can proceed with 
the deprecation. If we cannot, we'll likely have to delay the deprecation.

#23271 - Makemessages can 
corrupt existing .po files on Windows 

Owner: Ramiro
This week: no update
Last week's status: Ramiro said he would have some time to investigate the 
issue soon.

#23745 - Migrations migrate is slow 
 (new)
Owner: Claude
Status: Patch seems to need improvement so it doesn't cause a regression 
with swappable models.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b632fa62-3292-457c-bee0-87b1314d8a97%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: status of 1.8 release blockers

2014-12-21 Thread Markus Holtermann
Hey Tim,

thanks for the collection of tasks that have to be done for 1.8.

Especially wrt #23861 and #23891 I just realized that, since 1.8 is an LTS 
release, we'd need to support and that field (and related changes) until 
2018. That's Django 2.2/2.3 I guess. Considering the ideas that exists to 
tackle that problem, I'm almost certain the backporting overhead required 
for fixes is huge once the code is removed from the general releases. I'm 
not sure about #22340, though, but I wouldn't be surprised if that's the 
same. I don't think we should consider delaying the deprecation to 2.0 or 
later. From my perspective this has to be fixed and decided for 1.8. 
Otherwise we are going to make our life a living hell.

I'm happy to assist and answer questions, but I don't have the time to 
completely work out and write down a solution.

/Markus

On Saturday, December 20, 2014 8:40:33 PM UTC+1, Tim Graham wrote:
>
> As we approach the date for 1.8 alpha, I plan to send a weekly update on 
> the status of release blocking issues.
>
> We currently have 3 release blockers affecting master. You can use this 
> Trac filter to see them:
>
> https://code.djangoproject.com/query?status=assigned=new=master=Release+blocker
>
> You can also see other tickets we are targeting for 1.8 with this filter. 
> This includes some of the remaining large features as well as a couple code 
> reorganizations we want to make closer to when cut the 1.8 branch to avoid 
> creating conflicts with the large features that are in progress.
>
> https://code.djangoproject.com/query?status=assigned=new=~1.8-alpha
>
> Here is a summary of where we stand with each release blocker:
>
> #23861 - 
>  Fields referenced in 
> migrations cannot be (re)moved, even if migrations have been squashed 
>  Owner: ?
> Status: We need someone to investigate a strategy for how we can deprecate 
> model fields while keeping them available in historical migrations. Any 
> takers? If we cannot complete this, I propose we bump the deprecation of 
> IPAddressField until the issue is solved.
>
> #22340 -  
>  Legacy Table Creation 
> Methods Not Properly Deprecated 
>  Owner: Claude
> Status: This issue is being discussed in the thread "Migrations in Django 
> 1.7 make unit testing models harder". In short, we likely to need to solve 
> the performance issues with migrations before we can proceed with the 
> deprecation. If we cannot, we'll likely have to delay the deprecation.
>
> #23271 - Makemessages can 
> corrupt existing .po files on Windows 
> 
> Owner: Ramiro
> Status: Ramiro said he would have some time to investigate the issue soon.
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5abfe5b8-4f2a-4982-b97a-529c0cd2c9cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: status of 1.8 release blockers

2014-12-21 Thread Russell Keith-Magee
On Sun, Dec 21, 2014 at 6:38 PM, Riccardo Magliocchetti <
riccardo.magliocche...@gmail.com> wrote:
>
> Hello,
>
> Il 20/12/2014 20:40, Tim Graham ha scritto:
>
>> You can also see other tickets we are targeting for 1.8 with this
>> filter. This includes some of the remaining large features as well as a
>> couple code reorganizations we want to make closer to when cut the 1.8
>> branch to avoid creating conflicts with the large features that are in
>> progress.
>> https://code.djangoproject.com/query?status=assigned;
>> status=new=~1.8-alpha
>>
>
> Would be possible to add the better extends algorithm for templates to the
> desired stuff for 1.8 alpha? Code should be in pretty good shape but it's
> intertwined with Aymeric multiple template engine work.
>
> Ticket: https://code.djangoproject.com/ticket/15053
> PR: https://github.com/django/django/pull/3475/


Aymeric indicated he was going to land his template stuff in the next
couple of days, so that would give you a couple of weeks to work through
the last details and get it into trunk for a 1.8 release. In the meantime,
if you get a merge ready against his branch, you'll be ready to go as soon
as he lands his code.

Yours,
Russ Magee %-)

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq84_7pA%2BVD_T%2BQtXF5nL7U4CrJKO6iRahn33o_MyHiLa6fA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: status of 1.8 release blockers

2014-12-21 Thread Riccardo Magliocchetti

Hello,

Il 20/12/2014 20:40, Tim Graham ha scritto:

You can also see other tickets we are targeting for 1.8 with this
filter. This includes some of the remaining large features as well as a
couple code reorganizations we want to make closer to when cut the 1.8
branch to avoid creating conflicts with the large features that are in
progress.
https://code.djangoproject.com/query?status=assigned=new=~1.8-alpha


Would be possible to add the better extends algorithm for templates to 
the desired stuff for 1.8 alpha? Code should be in pretty good shape but 
it's intertwined with Aymeric multiple template engine work.


Ticket: https://code.djangoproject.com/ticket/15053
PR: https://github.com/django/django/pull/3475/

thanks,
riccardo

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5496A32C.604%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


status of 1.8 release blockers

2014-12-20 Thread Tim Graham
As we approach the date for 1.8 alpha, I plan to send a weekly update on 
the status of release blocking issues.

We currently have 3 release blockers affecting master. You can use this 
Trac filter to see them:
https://code.djangoproject.com/query?status=assigned=new=master=Release+blocker

You can also see other tickets we are targeting for 1.8 with this filter. 
This includes some of the remaining large features as well as a couple code 
reorganizations we want to make closer to when cut the 1.8 branch to avoid 
creating conflicts with the large features that are in progress.
https://code.djangoproject.com/query?status=assigned=new=~1.8-alpha

Here is a summary of where we stand with each release blocker:

#23861 - 
 Fields referenced in 
migrations cannot be (re)moved, even if migrations have been squashed 
 Owner: ?
Status: We need someone to investigate a strategy for how we can deprecate 
model fields while keeping them available in historical migrations. Any 
takers? If we cannot complete this, I propose we bump the deprecation of 
IPAddressField until the issue is solved.

#22340 -  
 Legacy Table Creation Methods 
Not Properly Deprecated  Owner: 
Claude
Status: This issue is being discussed in the thread "Migrations in Django 
1.7 make unit testing models harder". In short, we likely to need to solve 
the performance issues with migrations before we can proceed with the 
deprecation. If we cannot, we'll likely have to delay the deprecation.

#23271 - Makemessages can 
corrupt existing .po files on Windows 

Owner: Ramiro
Status: Ramiro said he would have some time to investigate the issue soon.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9ac2848f-8d2d-4480-8e1c-dbd8db164e18%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.