Re: Admin and CSS Custom Properties

2017-04-28 Thread Patrick Guido 
On 27 April 2017 at 23:18, Adam Johnson  wrote:

> Thanks for introducing me to a new CSS feature! I clearly don't keep up
> with front end stuff enough.
>
> Re: your issues:
>
> 1. From the support grid at the bottom of the Smashing Magazine article
> you linked, it looks like it's only IE 11 and Edge 14 that are major
> browsers that don't support it. However I feel like if Django is going to
> announce a feature like "you can override the Admin colours", it should
> work in all browsers. I'm not sure if we have a written policy for this
> though.
>
I guess it also depends on use cases, usually (where I work) we tend to
support only latest browsers when it comes to admin, since
it will be used by only a few people :) But I see your point.

A friend of mine was suggesting configuring colours in python, but this
means that the css would be rendered via python, which is
not ideal.
Another solution would be to add a JS polyfill to make it work on older
browsers, but I'm against it :)
Let's also keep in mind that this (if approved) will be included in django
2.0 or later, so the browser support will be even better :)


2. I'm not a huge fan of an additional HTTP request for every admin page
> load, for every admin site in existence whether or not the colours have
> been overridden. HTTP/2 isn't very widely deployed still so requests still
> ain't cheap.
>
Uhm, I think we can easily skip one request if the colours have not been
overridden. We can put the vars in base.css.
Then we can add the variables by changing the template (but that's more
cumbersome) either by adding an external css link
or by adding a style tag with the variables.


> 3. This can be overcome with a test to ensure the two files are in sync, I
> guess?
>
Uhm, true!


> And one more question: how much less painful is this to override the
> colours compared to the variable-less way, where you just clone the colour
> definitions of every rule in the original file in a second override file?
>
I haven't checked all the rules, but I think it will require quite a bit of
work. Maybe we can create a "template" file
that can be used to override quite easily the colours, but that doesn't
scale too well I think.


-- 
Patrick Guido Arminio

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAOUxZcugkWEnyx3wt7uXNYJE_Rgix-5N_iPwxMbZS73RA63%3DFw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Admin and CSS Custom Properties

2017-04-28 Thread Curtis Maloney 
I recently discovered that the stated "policy" on browser support in 
Admin is... well... not clear at all.


https://docs.djangoproject.com/en/1.11/faq/admin/#what-browsers-are-supported-for-using-the-admin

It claims to support full function for "YUI's A-Grade" browsers, but the 
link it provides does nothing to explain the supported versions, and a 
further "target environments matrix" link still lists IE6.


So perhaps it's time to update the FAQ, and have a discussion on what 
Admin's browser support policy needs to be updated to.


--
Curtis

On 28/04/17 19:14, Patrick Guido wrote:

On 27 April 2017 at 23:18, Adam Johnson mailto:m...@adamj.eu>> wrote:

Thanks for introducing me to a new CSS feature! I clearly don't keep
up with front end stuff enough.

Re: your issues:

1. From the support grid at the bottom of the Smashing Magazine
article you linked, it looks like it's only IE 11 and Edge 14 that
are major browsers that don't support it. However I feel like if
Django is going to announce a feature like "you can override the
Admin colours", it should work in all browsers. I'm not sure if we
have a written policy for this though.

I guess it also depends on use cases, usually (where I work) we tend to
support only latest browsers when it comes to admin, since
it will be used by only a few people :) But I see your point.

A friend of mine was suggesting configuring colours in python, but this
means that the css would be rendered via python, which is
not ideal.
Another solution would be to add a JS polyfill to make it work on older
browsers, but I'm against it :)
Let's also keep in mind that this (if approved) will be included in
django 2.0 or later, so the browser support will be even better :)


2. I'm not a huge fan of an additional HTTP request for every admin
page load, for every admin site in existence whether or not the
colours have been overridden. HTTP/2 isn't very widely deployed
still so requests still ain't cheap.

Uhm, I think we can easily skip one request if the colours have not been
overridden. We can put the vars in base.css.
Then we can add the variables by changing the template (but that's more
cumbersome) either by adding an external css link
or by adding a style tag with the variables.


3. This can be overcome with a test to ensure the two files are in
sync, I guess?

Uhm, true!


And one more question: how much less painful is this to override the
colours compared to the variable-less way, where you just clone the
colour definitions of every rule in the original file in a second
override file?

I haven't checked all the rules, but I think it will require quite a bit
of work. Maybe we can create a "template" file
that can be used to override quite easily the colours, but that doesn't
scale too well I think.


--
Patrick Guido Arminio

--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-developers+unsubscr...@googlegroups.com
.
To post to this group, send email to django-developers@googlegroups.com
.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAOUxZcugkWEnyx3wt7uXNYJE_Rgix-5N_iPwxMbZS73RA63%3DFw%40mail.gmail.com
.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/db7742bc-769b-85fe-af87-c398fa99215d%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Admin and CSS Custom Properties

2017-04-28 Thread Collin Anderson 
I suggest supporting IE11+, as that's the latest on Windows 7 and there's
not much 9-10 usage. Now's probably a good time to bump them if needed
because we're just past an LTS.

Though, yes, it doesn't allow CSS variables.

On Fri, Apr 28, 2017 at 6:38 AM, Curtis Maloney  wrote:

> I recently discovered that the stated "policy" on browser support in Admin
> is... well... not clear at all.
>
> https://docs.djangoproject.com/en/1.11/faq/admin/#what-brows
> ers-are-supported-for-using-the-admin
>
> It claims to support full function for "YUI's A-Grade" browsers, but the
> link it provides does nothing to explain the supported versions, and a
> further "target environments matrix" link still lists IE6.
>
> So perhaps it's time to update the FAQ, and have a discussion on what
> Admin's browser support policy needs to be updated to.
>
> --
> Curtis
>
> On 28/04/17 19:14, Patrick Guido wrote:
>
>> On 27 April 2017 at 23:18, Adam Johnson > > wrote:
>>
>> Thanks for introducing me to a new CSS feature! I clearly don't keep
>> up with front end stuff enough.
>>
>> Re: your issues:
>>
>> 1. From the support grid at the bottom of the Smashing Magazine
>> article you linked, it looks like it's only IE 11 and Edge 14 that
>> are major browsers that don't support it. However I feel like if
>> Django is going to announce a feature like "you can override the
>> Admin colours", it should work in all browsers. I'm not sure if we
>> have a written policy for this though.
>>
>> I guess it also depends on use cases, usually (where I work) we tend to
>> support only latest browsers when it comes to admin, since
>> it will be used by only a few people :) But I see your point.
>>
>> A friend of mine was suggesting configuring colours in python, but this
>> means that the css would be rendered via python, which is
>> not ideal.
>> Another solution would be to add a JS polyfill to make it work on older
>> browsers, but I'm against it :)
>> Let's also keep in mind that this (if approved) will be included in
>> django 2.0 or later, so the browser support will be even better :)
>>
>>
>> 2. I'm not a huge fan of an additional HTTP request for every admin
>> page load, for every admin site in existence whether or not the
>> colours have been overridden. HTTP/2 isn't very widely deployed
>> still so requests still ain't cheap.
>>
>> Uhm, I think we can easily skip one request if the colours have not been
>> overridden. We can put the vars in base.css.
>> Then we can add the variables by changing the template (but that's more
>> cumbersome) either by adding an external css link
>> or by adding a style tag with the variables.
>>
>>
>> 3. This can be overcome with a test to ensure the two files are in
>> sync, I guess?
>>
>> Uhm, true!
>>
>>
>> And one more question: how much less painful is this to override the
>> colours compared to the variable-less way, where you just clone the
>> colour definitions of every rule in the original file in a second
>> override file?
>>
>> I haven't checked all the rules, but I think it will require quite a bit
>> of work. Maybe we can create a "template" file
>> that can be used to override quite easily the colours, but that doesn't
>> scale too well I think.
>>
>>
>> --
>> Patrick Guido Arminio
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to django-developers+unsubscr...@googlegroups.com
>> .
>> To post to this group, send email to django-developers@googlegroups.com
>> .
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CAOUxZcu
>> gkWEnyx3wt7uXNYJE_Rgix-5N_iPwxMbZS73RA63%3DFw%40mail.gmail.com
>> > ugkWEnyx3wt7uXNYJE_Rgix-5N_iPwxMbZS73RA63%3DFw%40mail.
>> gmail.com?utm_medium=email&utm_source=footer>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/ms
> gid/django-developers/db7742bc-769b-85fe-af87-c398fa99215d%40tinbrain.net.
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are

Re: Admin and CSS Custom Properties

2017-04-28 Thread Patrick Guido 
On 28 April 2017 at 12:59, Collin Anderson  wrote:

> I suggest supporting IE11+, as that's the latest on Windows 7 and there's
> not much 9-10 usage. Now's probably a good time to bump them if needed
> because we're just past an LTS.
>
> Though, yes, it doesn't allow CSS variables.
>
Is it really an issue to use a feature that doesn't work on older browser
but doesn't degrade the experience?
If you use CSS variables with a fallback you will have the best of both
worlds.

The admin will continue working on old browsers, but on the new ones you
can use a custom color scheme.

-- 
Patrick Guido Arminio

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAOUxZcsnQALEyEXba%3D5PioXFGLMKQn3K5RxhTvhQ0MiswnZSiQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Organizing utilities for Django's test suite

2017-04-28 Thread Tim Graham 
About the module name for Django's test suite, "tests" doesn't feel 
intuitive to me. I think it should be more descriptive, like 
"django_test_utils", though I'm hardly advocating for that. "test_utils" is 
already taken as a module for testing django.test.utils. Anyone else have 
suggestions of conventions used for this sort of thing in other projects?

About capture_stdout(), etc. these are copied from cpython's test.support. 
I guess it could be nice to see if Python could make them public so Django 
doesn't have to.

On Thursday, April 27, 2017 at 1:53:43 PM UTC-4, Markus Holtermann wrote:
>
> Hey Tim,
>
> I think we can make a case for including this in django/tests/testcases.py 
> and in a new module tests/utils/something.py which is then only available 
> within Django's own the test suite. I think we should include that test 
> case as part of Django's own test suite for now. It's IMO easier to move 
> code from tests/utils/something.py to django/tests/something.py than vice 
> versa.
>
> That said, I think we should make capture_stdout()/err()/in() public API. 
> It's super helpful.
>
> /Markus
>
> On Thursday, April 27, 2017 at 6:57:34 PM UTC+2, Tim Graham wrote:
>>
>> At present, we have a number of functions in django.test.utils which 
>> aren't documented and are meant for use in Django's test suite. Things like:
>>
>> * extend_sys_path()
>> * isolate_lru_cache() 
>> * captured_stdout()/err()/in()
>> * freeze_time()
>> * require_jinja2()
>>
>> I have the need to reuse a WidgetTestCase from forms_tests in 
>> postgres_tests so I tentatively proposed putting it in 
>> django/test/testcases.py with a comment that it's not a public API [0]. 
>> Simon proposed creating a django/tests/tests/utils.py submodule (alongside 
>> runtests.py) instead of defining it in django.test since it's not meant to 
>> be a public API.
>>
>> Do you have any feelings about how to best organize things? I agree that 
>> mixing public and private things in django.test is not ideal. Another idea 
>> I had was to create something like django/test/_utils.py (underscore 
>> prefix) for private stuff. That would allow user code to continue using 
>> private APIs at their own risk (whereas putting test helpers in tests/ 
>> would not). 
>>
>> [0] https://github.com/django/django/pull/8425
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5c67523e-da75-4b9d-99f3-5dbf05d5a81c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improving MSSQL and Azure SQL support on Django

2017-04-28 Thread urijah 
I wonder if there have been any updates on MS support for a 
official/supported MS SQL Django driver? Did the offered engineering effort 
from MS ever come through? Given the availability of of MS SQL on Linux, as 
well as support for Django in Visual Studio, it would be great if this came 
to fruition.
Explicit support for Django with IronPython would also be nice, if MS would 
really want to take their Django support to the next level...

On Monday, March 7, 2016 at 5:37:06 PM UTC-5, Meet Bhagdev wrote:
>
> Hi all,
>
> On interacting with several Django developers and committers, one of the 
> questions often came up, can I use SQL Server on non Window OS's? I wanted 
> to share that today Microsoft announced SQL Server availibility on Linux - 
> https://blogs.microsoft.com/blog/2016/03/07/announcing-sql-server-on-linux/
> . 
>
> While there is still work needed to strengthen the MSSQL-Django story, we 
> hope this aids more Linux developers to give SQL Server a shot. Let me know 
> of your thoughts and questions :)
>
> Cheers,
> Meet
>
> On Monday, February 22, 2016 at 4:54:38 PM UTC-8, Vin Yu wrote:
>>
>> Hey Folks, 
>>
>> My name is Vin and I work with Meet in the Microsoft SQL Server team. 
>> Just wanted to let you all know we are still looking into how we can better 
>> improve and support MSSQL for the Django framework. We’ll continue to sync 
>> with Michael and let you know of any updates soon. 
>>
>> Christiano and Tim - thanks for sharing your interest and sharing how you 
>> are using Django with MSSQL. It's great to learn from your scenarios. 
>>
>> If you have any concerns, questions or comments feel free to reach out to 
>> me at vinsonyu[at]microsoft.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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8258f170-8f10-45fc-a1d3-9551efca6d1c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improving MSSQL and Azure SQL support on Django

2017-04-28 Thread Michael Manfre 
Quick update of the current status of things related to MSSQL. The most
actively maintained MSSQL backend that I'm aware of is django-pyodbc-azure
(also works with standalone SQL Server). Michiya has been doing an amazing
job supporting that backend. There has been no real movement toward there
being an officially supported MSSQL backend for Django. Microsoft has
continued to be involved with Django and myself related to making a better
MSSQL experience for us.

Regards,
Michael Manfre

On Fri, Apr 28, 2017 at 3:55 PM  wrote:

> I wonder if there have been any updates on MS support for a
> official/supported MS SQL Django driver? Did the offered engineering effort
> from MS ever come through? Given the availability of of MS SQL on Linux, as
> well as support for Django in Visual Studio, it would be great if this came
> to fruition.
> Explicit support for Django with IronPython would also be nice, if MS
> would really want to take their Django support to the next level...
>
>
> On Monday, March 7, 2016 at 5:37:06 PM UTC-5, Meet Bhagdev wrote:
>>
>> Hi all,
>>
>> On interacting with several Django developers and committers, one of the
>> questions often came up, can I use SQL Server on non Window OS's? I wanted
>> to share that today Microsoft announced SQL Server availibility on Linux -
>> https://blogs.microsoft.com/blog/2016/03/07/announcing-sql-server-on-linux/
>> .
>>
>> While there is still work needed to strengthen the MSSQL-Django story, we
>> hope this aids more Linux developers to give SQL Server a shot. Let me know
>> of your thoughts and questions :)
>>
>> Cheers,
>> Meet
>>
>> On Monday, February 22, 2016 at 4:54:38 PM UTC-8, Vin Yu wrote:
>>>
>>> Hey Folks,
>>>
>>> My name is Vin and I work with Meet in the Microsoft SQL Server team.
>>> Just wanted to let you all know we are still looking into how we can better
>>> improve and support MSSQL for the Django framework. We’ll continue to sync
>>> with Michael and let you know of any updates soon.
>>>
>>> Christiano and Tim - thanks for sharing your interest and sharing how
>>> you are using Django with MSSQL. It's great to learn from your scenarios.
>>>
>>> If you have any concerns, questions or comments feel free to reach out
>>> to me at vinsonyu[at]microsoft.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-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/8258f170-8f10-45fc-a1d3-9551efca6d1c%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAGdCwBv9HaNBAZMYWwqJ8rsfDUQe2zLuWgwMgh--1_XZsO%2BX%3Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Easier way to populate test databases for parallel tests (patch in github)

2017-04-28 Thread Marcos Diez 
Ticket:https://code.djangoproject.com/ticket/28153
Pull Request: https://github.com/django/django/pull/8437

Although Django makes very easy for one to extend 
django.test.runner.DiscoverRunner 
, it's setup_databases() does too much.

Currently, it

   - creates all the test databases (for single thread unit tests) 
   - duplicates all the test databases (in case of parallel unit tests) 

In case I am running not running tests in parallel, I can just populate the 
DB after running unit tests without any issues.


But if I care about my time and want to run tests in parallel, I can either:


a) populate my data after setup_databases() is executed, once for each 
thread of the parallel tests, which is slow
b) get my hands dirty and reimplement setup_databases() 


I propose (and I am sending the code to do so) a better solution. We just 
have to break setup_databases() in 3 functions:


DiscoverRunner.prepare_databases() 
DiscoverRunner.populate_databases() # noop by default 
DiscoverRunner.duplicate_databases_if_necessary()


The idea is quite simple: in order to be backward compatible, setup_databases() 
, will still exist but only call three functions above in that order.


The first function will create all the test databases necessary for non 
parallel tests to run.

populate_databases() , which should be a no op, can be overwritten by the 
user who extends django.test.runner.DiscoverRunner so his/her data can be 
populated 


Afterwards, all the test DBs are copied as many times as necessary in case 
parallel tests are run via DiscoverRunner.duplicate_databases_if_necessary() 



I believe this change on Django will have no downside, will be backward 
compatible and help people who needs to populate real data on the DB for 
their tests.


Thanks

Marcos Diez

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5f3ff10a-a0a7-4142-87a6-4820e4358807%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Easier way to populate test databases for parallel tests (patch in github)

2017-04-28 Thread Tim Graham 
I would expect test data population to happen using migrations rather than 
in the test runner. Can you elaborate on your use case and say if that 
method would be unsuitable?

On Friday, April 28, 2017 at 8:45:55 PM UTC-4, Marcos Diez wrote:
>
> Ticket:https://code.djangoproject.com/ticket/28153
> Pull Request: https://github.com/django/django/pull/8437
>
> Although Django makes very easy for one to extend 
> django.test.runner.DiscoverRunner 
> , it's setup_databases() does too much.
>
> Currently, it
>
>- creates all the test databases (for single thread unit tests) 
>- duplicates all the test databases (in case of parallel unit tests) 
>
> In case I am running not running tests in parallel, I can just populate 
> the DB after running unit tests without any issues.
>
>
> But if I care about my time and want to run tests in parallel, I can 
> either:
>
>
> a) populate my data after setup_databases() is executed, once for each 
> thread of the parallel tests, which is slow
> b) get my hands dirty and reimplement setup_databases() 
>
>
> I propose (and I am sending the code to do so) a better solution. We just 
> have to break setup_databases() in 3 functions:
>
>
> DiscoverRunner.prepare_databases() 
> DiscoverRunner.populate_databases() # noop by default 
> DiscoverRunner.duplicate_databases_if_necessary()
>
>
> The idea is quite simple: in order to be backward compatible, 
> setup_databases() 
> , will still exist but only call three functions above in that order.
>
>
> The first function will create all the test databases necessary for non 
> parallel tests to run.
>
> populate_databases() , which should be a no op, can be overwritten by the 
> user who extends django.test.runner.DiscoverRunner so his/her data can be 
> populated 
>
>
> Afterwards, all the test DBs are copied as many times as necessary in case 
> parallel tests are run via DiscoverRunner.duplicate_databases_if_necessary() 
>
>
>
> I believe this change on Django will have no downside, will be backward 
> compatible and help people who needs to populate real data on the DB for 
> their tests.
>
>
> Thanks
>
> Marcos Diez
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/817344bd-57c1-42e9-a5b6-8550934c89b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.