status of 1.9 release blockers

[Tim Graham]

Time to kickoff the progress tracker for the next major release!

Here's the status with 4 weeks to go until alpha (September 21).

Release blockers:

- Add Oracle support for new-style GIS functions
https://code.djangoproject.com/ticket/24688
Owner: Jani Tiainen
Status: In progress (test suite runs on Oracle now, which is an improvement from last week)


Other tickets tagged for 1.9:

- No way to create tables for apps without migrations
https://code.djangoproject.com/ticket/25144
Status: Awaiting replies to "Keeping apps without migrations?" thread for a decision on what to do
Mailing list thread: https://groups.google.com/d/topic/django-developers/qHP4ZQSK9xM/discussion
Owner: pending discussion

- Replace admin icons images by inline SVG
https://code.djangoproject.com/ticket/20597
Owner: elky
Status: In progress

- Update tutorial screenshots for new admin theme
https://code.djangoproject.com/ticket/25200
Status: to be done after previous item is completed


Relevant ticket filters:

Release blockers affecting master:
https://code.djangoproject.com/query?status=assigned&status=new&version=master&severity=Release+blocker

Tickets tagged 1.9:
https://code.djangoproject.com/query?status=assigned&status=new&keywords=~1.9

[Tim Graham]

Status with 2 weeks and a weekend to go until alpha (Monday, September 21).

Planned major features for 1.9:

PostgreSQL Full Text Search (Marc Tamlyn)

I haven't seen any recent activity on the pull request, nor have I heard anything from Marc about it.

https://github.com/django/django/pull/4726

Custom indexes (Marc Tamlyn)

I haven't see any work on revising the DEP, so this seem out for 1.9.

https://github.com/django/deps/pull/6

Template-based widget rendering (Preston Timmons)
I think the code is in fairly good shape. It seems the main work left to is to write documentation.
https://github.com/django/django/pull/4848

Release blockers:

- Add Oracle support for new-style GIS functions
https://code.djangoproject.com/ticket/24688
Owner: Jani Tiainen

Status: In progress (from recent IRC discussion, it sounds like Jani is making good progress)

[Tim Graham]

With 1 week to go until alpha:

I haven't heard anything from Marc or Preston on the major features from the last mail.

Jani continues to give updates in #django-dev about his progress on getting the Oracle GIS backend working. Things seem to be on track for finishing up by alpha.

[Tim Graham]

The major features are officially deferred. Let's try for the feature freeze by end of day on Monday and the alpha release on Tuesday.

There aren't any critical blockers at this time. Jani hasn't completed the Oracle GIS work, but this isn't a must-have for alpha.

[Marc Tamlyn]

Sorry everyone :(

--
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/261819cf-fb09-4e6b-b162-d2cdc76f3807%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Tim Graham]

Let's consider master feature frozen for now. There are two more patches I'd like to merge before we cut the 1.9 branch.

#21231 -- Enforced a max size for POST values read into memory
https://github.com/django/django/pull/3852
Status: Needs final code reviews and probably some doc enhancements (docs could possibly be deferred until after alpha). Florian & Shai, as you've been taking the lead on reviewing this, please let us know your thoughts.

#24509 -- Added Expression support to SQLInsertCompiler
https://github.com/django/django/pull/5324
Status: Josh working on some doc enhancements now, I will review in the morning.

[Tim Graham]

The second patch has been committed, and the first one is still under review.

Florian says "with all that forth and back [on the pull request] I am not sure if it is not better to defer it to 1.10, i.e. I completely missed the base64 stuff for instance. One option would be to ship it with the feature inactive and mark it as experimental and ask users to try it out. Though, that would probably be a first."

I'd also be more comfortable if it were disabled by default. The main problem for me is the documentation doesn't really motivate the feature very well and describe how one should go about setting the values of the new settings.

Options:
1) Defer the patch to 1.10 and release the alpha today.
2) Maintain the feature freeze until the end of the week to see if the patch is better resolved by then (fix bugs on master in the meantime) and release the alpha then (whether or not the patch is completed).
3) Create the 1.9 branch today to allow normal development to proceed on master and release the alpha by the end of the week with the option to backport the patch if it's completed.

Opinions?

[Russell Keith-Magee]

On Wed, Sep 23, 2015 at 12:54 AM, Tim Graham <timog...@gmail.com> wrote:
> The second patch has been committed, and the first one is still under
> review.
>
> Florian says "with all that forth and back [on the pull request] I am not
> sure if it is not better to defer it to 1.10, i.e. I completely missed the
> base64 stuff for instance. One option would be to ship it with the feature
> inactive and mark it as experimental and ask users to try it out. Though,
> that would probably be a first."
>
> I'd also be more comfortable if it were disabled by default. The main
> problem for me is the documentation doesn't really motivate the feature very
> well and describe how one should go about setting the values of the new
> settings.
>
> Options:
> 1) Defer the patch to 1.10 and release the alpha today.
> 2) Maintain the feature freeze until the end of the week to see if the patch
> is better resolved by then (fix bugs on master in the meantime) and release
> the alpha then (whether or not the patch is completed).
> 3) Create the 1.9 branch today to allow normal development to proceed on
> master and release the alpha by the end of the week with the option to
> backport the patch if it's completed.
>
> Opinions?

For me, it depends on how close Florian et al think the patch is. If
it's "close, but a few things need to be tweaked", then option 2 or 3
sounds good to me. A couple of days won't make much difference in the
overall schedule, so whichever is easier for Tim to manage works for
me. If it's "oh no, we missed this major use case", then option 1 is
probably where we are.

Russ %-)

[Florian Apolloner]

On Wednesday, September 23, 2015 at 2:25:50 AM UTC+2, Russell Keith-Magee wrote:

For me, it depends on how close Florian et al think the patch is. If
it's "close, but a few things need to be tweaked", then option 2 or 3
sounds good to me. A couple of days won't make much difference in the
overall schedule, so whichever is easier for Tim to manage works for
me. If it's "oh no, we missed this major use case", then option 1 is
probably where we are.

My time this week is basically zero, someone else would have to make the decission (I will probably without internet starting on friday). Whatever works for Tim should be fine for me though.

Cheers,
Florian

[Tom Christie]

Given that it addresses such a core component I'd probably rather see it deferred to 1.10.

I'd hope that doesn't affect the motivation of the author (it's a fiddly bit of work to get right and its good to see it being addressed) but from my point of view it'd be better to see it really thoroughly reviewed before commit.

As one example it's not clear what the preferred resolution of this point should be. Should the `DATA_UPLOAD_MAX_MEMORY_SIZE` guard include accessing `request.body` directly or not? (Related to Tim's point re. documentation.)

As I say, its good work, and I'd like to see it reach completion, but its not the sort of change we should be rushing.

(I wouldn't oppose a contrary judgement on it tho)

[Tom Christie]

To back that up I'll make a formal commitment to helping review & ensure completion of the PR if it *does* get deferred to 1.10.

[Markus Holtermann]

I did not fully follow the discussion, but by the amount of email notifications I got on that PR if feels to me that deferring it to 1.10 would be the better option, also considering what Tom said about this being part of a core component and it has to be done right.

/Markus

[Tim Graham]

I'm okay with deferring it. I'll see if we can release the alpha later today then. I found one regression in the unreviewed ticket queue this morning and submitted a pull request. I'm also investigating a possible regression causing the djangoproject.com tests to fail.

[Tim Graham]

All known issues are resolved. I plan to create the branch and make the release in about 4 hours if nothing else pops up.

[Tim Graham]

We've resolved a couple of release blockers on the stable/1.9.x branch since the alpha, but overall bug reports have been quiet. Hopefully that's a good sign!

The beta release is scheduled for 2 weeks + 2 days from now, Monday October 19.

[Tim Graham]

We're on schedule for Monday's beta release. Most of the backported fixes have been issues affecting 1.8 too.

[Tim Graham]

Sorry for the lack of updates, but no news is good news. We're on track for a release candidate on Monday.

[Tim Graham]

We're on schedule for 1.9 final tomorrow. There are 3 release blockers in Trac, however, 1 blocker affects only master and the other two also affect 1.8 and thus aren't blockers for 1.9.