status of 1.8 release blockers
1,955 views
Skip to first unread message
Tim Graham
Dec 20, 2014, 2:40:33 PM12/20/14
to django-d...@googlegroups.com
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&status=new&version=master&severity=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&status=new&keywords=~1.8-alpha
Here is a summary of where we stand with each release blocker:
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.
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.
We currently have 3 release blockers affecting master. You can use this Trac filter to see them:
https://code.djangoproject.com/query?status=assigned&status=new&version=master&severity=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&status=new&keywords=~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 |
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 |
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.
Riccardo Magliocchetti
Dec 21, 2014, 5:39:01 AM12/21/14
to django-d...@googlegroups.com
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&keywords=~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
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&keywords=~1.8-alpha
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
Russell Keith-Magee
Dec 21, 2014, 6:43:25 PM12/21/14
to Django Developers
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 %-)
Markus Holtermann
Dec 21, 2014, 7:50:21 PM12/21/14
to django-d...@googlegroups.com
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
Tim Graham
Dec 27, 2014, 10:46:52 AM12/27/14
to django-d...@googlegroups.com
Here is the second update with three weeks to go until alpha:
#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.
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.
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.
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.
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.
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.
Claude Paroz
Dec 29, 2014, 4:40:06 AM12/29/14
to django-d...@googlegroups.com
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
Markus Holtermann
Dec 30, 2014, 7:49:59 AM12/30/14
to django-d...@googlegroups.com
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
Tim Graham
Dec 30, 2014, 4:29:27 PM12/30/14
to django-d...@googlegroups.com
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!):
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.
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.
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.
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.
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.
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.
Now: Resolved by Ramio
Last time: no update
Last time: no update
Tim Graham
Jan 3, 2015, 11:09:04 AM1/3/15
to django-d...@googlegroups.com
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.
#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&keywords=~1.8-alpha
Resolved since last time:
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&keywords=~1.8-alpha
Resolved since last time:
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.
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.
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.
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.
Jeremy Dunck
Jan 3, 2015, 1:19:25 PM1/3/15
to django-d...@googlegroups.com
Thank you, Tim, for shepherding this.
--
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.
Tim Graham
Jan 9, 2015, 1:14:02 PM1/9/15
to django-d...@googlegroups.com
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:
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:
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:
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&keywords=~1.8-alpha
Tim Graham
Jan 12, 2015, 9:25:23 PM1/12/15
to django-d...@googlegroups.com
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.
Tino de Bruijn
Jan 13, 2015, 1:50:26 AM1/13/15
to django-d...@googlegroups.com
Congratulations! Looks like you've steadily moved it through.
Tino
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/15aaad79-b702-4bb4-a3dd-b341ed140aab%40googlegroups.com.
Tim Graham
Jan 15, 2015, 8:30:04 PM1/15/15
to django-d...@googlegroups.com
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.
Tim Graham
Feb 4, 2015, 9:45:33 AM2/4/15
to django-d...@googlegroups.com
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&status=new&version=1.8alpha1&severity=Release+blocker&or&status=assigned&status=new&keywords=~1.8-beta&col=id&col=summary&col=status&col=owner&col=type&col=component&col=changetime&desc=1&order=changetime
I'll follow up next week to ensure we have owners for any issues that remain after the weekend.
Please check this filter for remaining blockers for beta:
https://code.djangoproject.com/query?status=assigned&status=new&version=1.8alpha1&severity=Release+blocker&or&status=assigned&status=new&keywords=~1.8-beta&col=id&col=summary&col=status&col=owner&col=type&col=component&col=changetime&desc=1&order=changetime
I'll follow up next week to ensure we have owners for any issues that remain after the weekend.
Tim Graham
Feb 12, 2015, 8:33:38 PM2/12/15
to django-d...@googlegroups.com
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&status=new&version=1.8alpha1&severity=Release+blocker&or&keywords=~1.8-beta&status=assigned&status=new&or&keywords=~1.8&status=assigned&status=new&col=id&col=summary&col=status&col=owner&col=type&col=component&col=changetime&desc=1&order=changetime
#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&status=new&version=1.8alpha1&severity=Release+blocker&or&keywords=~1.8-beta&status=assigned&status=new&or&keywords=~1.8&status=assigned&status=new&col=id&col=summary&col=status&col=owner&col=type&col=component&col=changetime&desc=1&order=changetime
Markus Holtermann
Feb 12, 2015, 8:49:35 PM2/12/15
to django-d...@googlegroups.com
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 <timog...@gmail.com> wrote:
>Status of release blockers:
>
>#24320 <https://code.djangoproject.com/ticket/24320> Unable to
>#24264 <https://code.djangoproject.com/ticket/24264> foreign key
>>>>>> #24075 <https://code.djangoproject.com/ticket/24075> - Can't
>>>>>>>> <https://code.djangoproject.com/ticket/23861> Fields referenced
>>>>>>>> #23891 <https://code.djangoproject.com/ticket/23891> - Revise
>>>>>>>> .
>>>>> .
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 <timog...@gmail.com> wrote:
>Status of release blockers:
>
>serialize
>UUIDField when running dumpdata with JSON format
><https://code.djangoproject.com/ticket/24320>
>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 <https://code.djangoproject.com/ticket/24289> Is usage of
>if no
>one else takes a look first.
>
>many_to_one and one_to_many terms confusing for relation flags?
><https://code.djangoproject.com/ticket/24289>
>Status: We are waiting for feedback/confirmation from Anssi and Russ
>about
>the direction to take here.
>
>#24225 <https://code.djangoproject.com/ticket/24225> KeyError when
>about
>the direction to take here.
>
>migrating in 1.8a1/master@728b6fd (does not occur in 1.7.3)
><https://code.djangoproject.com/ticket/24225>
>#24264 <https://code.djangoproject.com/ticket/24264> foreign key
>constraint
>error migrating integer pk to CharField
><https://code.djangoproject.com/ticket/24264>
>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 <https://code.djangoproject.com/ticket/24282> Cannot Modify
>shape
>and should be ready for commit soon.
>
>Foreign
>Keys Within Data Migrations
><https://code.djangoproject.com/ticket/24282>
>Keys Within Data Migrations
>migrate
>>>>>> contenttypes and auth to zero
>>>>>> <https://code.djangoproject.com/ticket/24075>
>>>>>> 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 -
>>>>>> <https://code.djangoproject.com/ticket/23861> Fields referenced
>>>>>> 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 -
>in
>>>>>> migrations cannot be (re)moved, even if migrations have been
>squashed
>>>>>> <https://code.djangoproject.com/ticket/23861>
>>>>>> migrations cannot be (re)moved, even if migrations have been
>squashed
>in
>>>>>>>> migrations cannot be (re)moved, even if migrations have been
>squashed
>>>>>>>> <https://code.djangoproject.com/ticket/23861>
>>>>>>>> migrations cannot be (re)moved, even if migrations have been
>squashed
>>>>>>>> #23891 <https://code.djangoproject.com/ticket/23891> - Revise
>>>>>>>> deprecation / removal timeline for IPAddressField
>>>>>>>> <https://code.djangoproject.com/ticket/23891> (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&keywords=~1.8-alpha
>>>>>>>>
>>>>>>>> Resolved since last time:
>>>>>>>>
>>>>>>>> #22340 -
>>>>>>>> <https://code.djangoproject.com/ticket/22340> Legacy Table
>>>>>>>> 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&keywords=~1.8-alpha
>>>>>>>>
>>>>>>>> Resolved since last time:
>>>>>>>>
>>>>>>>> #22340 -
>Creation
>>>>>>>> Methods Not Properly Deprecated
>>>>>>>> <https://code.djangoproject.com/ticket/22340>
>>>>>>>> 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
>>>>>>>> <https://code.djangoproject.com/ticket/23745>
>>>>>>>> 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
>>>>>>>>
><https://groups.google.com/d/msgid/django-developers/b196f095-530c-45ec-9b21-82fcd1c06ed8%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>>>> 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
>>>>>>>> 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-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/15aaad79-b702-4bb4-a3dd-b341ed140aab%40googlegroups.com
>
>>>>>
><https://groups.google.com/d/msgid/django-developers/15aaad79-b702-4bb4-a3dd-b341ed140aab%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>>>>
>>>>>>> --
>>>>> 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/15aaad79-b702-4bb4-a3dd-b341ed140aab%40googlegroups.com
>
>>>>>
>>>>> .
Markus Holtermann
Feb 13, 2015, 1:30:44 PM2/13/15
to django-d...@googlegroups.com
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
Tim Graham
Feb 16, 2015, 11:12:46 AM2/16/15
to django-d...@googlegroups.com
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.
Tim Graham
Feb 16, 2015, 7:05:37 PM2/16/15
to django-d...@googlegroups.com
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
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().
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.
#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. |
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/ShaiStatus: 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.
Markus Holtermann
Feb 17, 2015, 10:06:27 AM2/17/15
to django-d...@googlegroups.com
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
Tim Graham
Feb 17, 2015, 12:20:22 PM2/17/15
to django-d...@googlegroups.com
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.
Marten Kenbeek
Feb 17, 2015, 12:40:40 PM2/17/15
to django-d...@googlegroups.com
@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:
Op dinsdag 17 februari 2015 18:20:22 UTC+1 schreef Tim Graham:
Tim Graham
Feb 17, 2015, 7:38:41 PM2/17/15
to django-d...@googlegroups.com
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.
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.
Status: Mostly committed. Waiting for reply from Berker regarding a couple of his review comments.
Status: Waiting for feedback on API design (see mailing list thread).
Status: Patch still in progress.
Status: Josh thinks the patch is RFC. Awaiting final review from anyone interested.
Status: Patch looks good to me (again).
Tim Graham
Feb 18, 2015, 10:10:20 PM2/18/15
to django-d...@googlegroups.com
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.
Status: In review.
Status: In review.
Status: Marc to polish patch.
Loïc Bistuer
Feb 19, 2015, 2:45:07 AM2/19/15
to django-d...@googlegroups.com
From my point of view #24351 is ready for a final sanity check and merging.
--
Loïc
--
Loïc
> --
> 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.
> 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.
Tim Graham
Feb 20, 2015, 4:48:01 PM2/20/15
to django-d...@googlegroups.com
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
#24377 UUIDField as primary key breaks inline admins
Tim Graham
Feb 21, 2015, 3:53:51 PM2/21/15
to django-d...@googlegroups.com
Patches for the two remaining blockers are awaiting review.
#24381 Cache pickling exception in 1.8a1 with cross-table filter params
#24381 Cache pickling exception in 1.8a1 with cross-table filter params
Tim Graham
Feb 23, 2015, 7:29:09 PM2/23/15
to django-d...@googlegroups.com
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.
#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.
Tim Graham
Feb 24, 2015, 8:08:39 PM2/24/15
to django-d...@googlegroups.com
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).
Raúl Cumplido
Feb 25, 2015, 3:43:15 AM2/25/15
to django-d...@googlegroups.com
\o/
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/7d933ca2-ed55-408b-bdce-551060e24d54%40googlegroups.com.
Tim Graham
Mar 7, 2015, 10:54:30 AM3/7/15
to django-d...@googlegroups.com
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.
Tim Graham
Mar 14, 2015, 4:45:21 PM3/14/15
to django-d...@googlegroups.com
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).
Tim Graham
Mar 28, 2015, 8:28:45 PM3/28/15
to django-d...@googlegroups.com
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.
Reply all
Reply to author
Forward
0 new messages