Re: Should we require pytz for timezone support in Django?

Corresponding ticket - #26622 On Tuesday, 17 May 2016 05:51:29 UTC+5:30, Josh Smeaton wrote: > > While writing timezone tests for > https://github.com/django/django/pull/6243 I ran into some issues where > pytz seemed to be required for just about

Re: Should we require pytz for timezone support in Django?

Corresponding ticket - #26622 . On Tuesday, 17 May 2016 05:51:29 UTC+5:30, Josh Smeaton wrote: > > While writing timezone tests for > https://github.com/django/django/pull/6243 I ran into some issues where > pytz seemed to be required for just about

Re: Tracking/logging bruteforcing, especially on admin accounts?

Le vendredi 20 mai 2016 02:44:41 UTC+2, Josh Smeaton a écrit : > > I understand the reasoning for "use the cache", but not every site has > caching enabled, especially lots of smaller sites. > That's not true. When not specified, the cache backend default to the local memory cache:

Re: Organizing the built-in system check framework's hint messages

On Thu, May 19, 2016 at 02:56:48PM -0700, Quentin Fulsher wrote: > Here is a super quick proof of concept that I put together. I just branched > my fork of django and added a little to it. Here is the comparing changes > page[1]. > > Quick summary of changes: I created a dictionary that would

Testing pre-release Django

Hi, I have the general feeling that too few people are testing the new Django major releases before the .0 release. The result being that many regressions are often reported after the release, while those could have been detected at alpha/beta/rc stages. I found myself in the situation where

[ANNOUNCE] Django 1.10 alpha 1 released

We've made the first release on the way to Django's next major release, Django 1.10! With two and a half months until the scheduled final release, we'll need timely testing from the community to ensure an on-time and stable release. Check out the blog post:

Re: Testing pre-release Django

I'm completely supportive of this effort. In past release cycles, I've done testing with djangoproject.com and sent some PRs to its dependencies. The blocker to upgrading is always waiting for each project to make a release with the fixes. We could provide some guidance and suggest that

Re: Testing pre-release Django

Another idea might be to encourage more packages to test on Travis against Django master (with that sub-job marked as allowed to fail, so it doesn't fail the whole run) - so any incompatibilities become apparent earlier. eg:

Re: Testing pre-release Django

Please test your projects against django master too. On May 21, 2016 1:31 AM, "Ed Morley" wrote: > Another idea might be to encourage more packages to test on Travis against > Django master (with that sub-job marked as allowed to fail, so it doesn't > fail the whole run) -