Re: [Django] #32219: Use Admin Inline verbose_name as default for Inline verbose_name_plural

[Django]

#32219: Use Admin Inline verbose_name as default for Inline verbose_name_plural
-+-
 Reporter:  Siburg   |Owner:  Siburg
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:  Admin Inline | Triage Stage:
  verbose_name_plural|  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Siburg):

 * owner:  nobody => Siburg
 * status:  new => assigned


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.ff0683fd9ad874daf4669ce6886e412f%40djangoproject.com.

[Django] #32219: Use Admin Inline verbose_name as default for Inline verbose_name_plural

[Django]

#32219: Use Admin Inline verbose_name as default for Inline verbose_name_plural
-+-
   Reporter:  Siburg |  Owner:  nobody
   Type:  New| Status:  new
  feature|
  Component: |Version:  3.1
  contrib.admin  |   Keywords:  Admin Inline
   Severity:  Normal |  verbose_name_plural
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Django allows specification of a verbose_name and a verbose_name_plural
 for Inline classes in admin views. However, verbose_name_plural for an
 Inline is not currently based on a specified verbose_name. Instead, it
 continues to be based on the model name, or an a verbose_name specified in
 the model's Meta class. This was confusing to me initially (I didn't
 understand why I had to specify both name forms for an Inline if I wanted
 to overrule the default name), and seems inconsistent with the approach
 for a model's Meta class (which does automatically base the plural form on
 a specified verbose_name). I propose that verbose_name_plural for an
 Inline class should by default be based on the verbose_name for an Inline
 if that is specified.

 I have written a patch to implement this, including tests. Would be happy
 to submit that.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/049.8be5496c51f2c6debead9c99b02f983c%40djangoproject.com.

Re: [Django] #32191: Not RFC 6265 compliant cookies in contrib.messages.

[Django]

#32191: Not RFC 6265 compliant cookies in contrib.messages.
--+---
 Reporter:  Nico Giefing  |Owner:  Craig Smith
 Type:  Bug   |   Status:  assigned
Component:  contrib.messages  |  Version:  3.1
 Severity:  Normal|   Resolution:
 Keywords:  Cookie malformed  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+---

Comment (by Craig Smith):

 Hi All, I've updated the PR with the `compress_b64encode` and
 `b64decode_decompress` methods extracted into the `django.core.signing`
 module. I could use some help with the names, should they be `compress`
 and `decompress` or mention the b64 encoding as in the current PR?

 Also, the encoding from string to bytestring and back again needs some
 thinking. If the compress/decompress methods are going to be used by
 client code (as indeed they might be to extract raw messages from
 `req.cookies['messages'].value`) then getting `decompress` to return a
 string instead of a bytestring would be better. And `compress` should be
 modified to accept a string. That will probably be my next step when I get
 back to this during the week.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.de7544e148679821808896030816d2f2%40djangoproject.com.

Re: [Django] #31639: Allow using lookup and transforms in F() and OuterRef().

[Django]

#31639: Allow using lookup and transforms in F() and OuterRef().
-+-
 Reporter:  Baptiste Mispelon|Owner:  Ian Foote
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ian Foote):

 * needs_docs:  1 => 0
 * needs_tests:  1 => 0


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.5dc8ff1f3f8c45aa3b900bf4ed144ef0%40djangoproject.com.

Re: [Django] #25534: Allow using lookups in aggregates.

[Django]

#25534: Allow using lookups in aggregates.
-+-
 Reporter:  Raúl Pedro Santos|Owner:  Ian Foote
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ian Foote):

 * needs_docs:  1 => 0
 * needs_tests:  1 => 0


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.f5fe92873c20f91ba5eecc5d6e6a2622%40djangoproject.com.

Re: [Django] #32217: Add warning about missing 'migrations' package to migration docs

[Django]

#32217: Add warning about missing 'migrations' package to migration docs
-+-
 Reporter:  Tim McCurrach|Owner:  Tim
 Type:   |  McCurrach
  Cleanup/optimization   |   Status:  new
Component:  Documentation|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim McCurrach):

 * status:  closed => new
 * resolution:  invalid =>


Comment:

 Thank you very much for taking the time to look at this :)

 In spite of the above quotes from the docs, I still think that this is not
 clear enough in the documentation.

 To clarify what I think needs highlighting:
  - it is not that running "makemigrations app_name" will create a
 migrations directory. That is clear enough, and not knowing it doesn't
 have any real consequences since it is trivial to create a folder.
  - What I don't think is particularly clear is that "''if you have not
 created a migrations folder, running makemigrations by itself will do
 absolutely nothing''". **Not knowing this piece of information can
 completely stop the progress of your project - and so it is vital that it
 is communicated clearly.**

 The first quote above (from the django-admin docs page) does perhaps imply
 that just running makemigrations by itself might not work if your app
 doesn't already have a migrations folder, but it certainly doesn't make it
 explicit.

 I don't think the second quote (from the settings docs page) even implies
 it. It reads as a nice extra that makemigrations will do for you. (I admit
 that if you spent a moment to think that without a migrations folder,
 there won't be any migtations, and that if adding the app_name means a
 migrations folder will be created then perhaps without the app_name a
 migrations folder won't be created, hence no migrations. But I really
 think it could be made a lot more explicit than that.)

 Further to the above (and perhaps more importantly), if I have a problem
 with migrations, I'm unlikely to look at the django-admin docs page, or to
 look up an obscure setting. This information really should be on the
 migrations page. Even googling "django makemigrations" directs you towards
 the migrations page. **Given the difficulty caused by not knowing this, it
 should be impossible for someone to read the migrations page in the docs
 and still not know it.**

 Especially as it seems like such an easy trap to fall into.

 Perhaps it's my reading of the docs is off, and if the feeling is still
 that this is already stated clearly then I accept that. (But to my mind it
 seems like it's a point that should be made clearer).

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.12490beb2b3e77190ff0f83770cfedfb%40djangoproject.com.

Re: [Django] #32218: storage.StaticFilesStorage.post_process substitutes relative URLs in comments

[Django]

#32218: storage.StaticFilesStorage.post_process substitutes relative URLs in
comments
-+-
 Reporter:  Gagan Deep   |Owner:  Gagan
 |  Deep
 Type:  Bug  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  master
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  static   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * status:  assigned => closed
 * resolution:   => duplicate


Comment:

 Duplicate of #21080.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.f976d5ae67dae9c2b57987f1beafe7d3%40djangoproject.com.

Re: [Django] #32217: Add warning about missing 'migrations' package to migration docs

[Django]

#32217: Add warning about missing 'migrations' package to migration docs
-+-
 Reporter:  Tim McCurrach|Owner:  Tim
 Type:   |  McCurrach
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  3.1
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * status:  assigned => closed
 * resolution:   => invalid


Comment:

 This behavior is already documented in the `makemigrations`
 [https://docs.djangoproject.com/en/3.1/ref/django-admin/#makemigrations
 docs]:
 {{{
 To add migrations to an app that doesn't have a migrations directory, run
 makemigrations with the app's app_label.
 }}}
 and in the `MIGRATION_MODULES`
 [https://docs.djangoproject.com/en/3.1/ref/settings/#std:setting-
 MIGRATION_MODULES docs]:
 {{{
 If you provide the app_label argument, makemigrations will automatically
 create the package if it doesn’t already exist.

 When you supply None as a value for an app, Django will consider the app
 as an app without migrations regardless of an existing migrations
 submodule.
 }}}
 I think that's enough.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.a539de0ab93c0561f49f24526fa69dd3%40djangoproject.com.

[Django] #32218: storage.StaticFilesStorage.post_process substitutes relative URLs in comments

[Django]

#32218: storage.StaticFilesStorage.post_process substitutes relative URLs in
comments
-+-
   Reporter:  Gagan  |  Owner:  Gagan Deep
  Deep   |
   Type:  Bug| Status:  assigned
  Component: |Version:  master
  contrib.staticfiles|
   Severity:  Normal |   Keywords:  static
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 While using {{{ STATICFILES_STORAGE =
 'django.contrib.staticfiles.storage.ManifestStaticFilesStorage' }}}
 setting, the {{{ collectstatic }}} command was always failing because it
 was not able to find a certain file. I am getting the following error:

 {{{

 ValueError: The file 'netjsongraph/css/lib/"images/ui-
 icons_55_256x240.png"' could not be found with
 .

 }}}

 The peculiar thing to notice is the name of the missing file contains {{{
 " }}}. Initially I thought it might me an error in the CSS, but even after
 removing all CSS properties using {{{ url() }}} functions, the error was
 still there.
 The error disappeared only after I removed the comment in the CSS file
 which contained {{{ url(%22images%2Fui-icons_55_256x240.png%22) }}} as
 a parameter to some URL.

 The {{{ post_process }}} should not try to make substitutions for {{{ url
 }}} keyword inside comments. Since it pattern matching is used to make
 substitutions, it will be better to process files without comments for
 pattern matching.

 You can use [https://github.com/openwisp/openwisp-network-
 
topology/blob/485a97bcc273fc4dfbb53f509f70a4825fab5a0f/openwisp_network_topology/static/netjsongraph/css/lib
 /jquery-ui.min.css this CSS file] for reproducing this bug.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.0a9d7359dfd3a12b8d93fc0d65eb5e9f%40djangoproject.com.

Re: [Django] #32216: Can not execute tests with spatialite as database backend

[Django]

#32216: Can not execute tests with spatialite as database backend
-+--
 Reporter:  thegreathir  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  3.1
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by Mariusz Felisiak):

 * status:  new => closed
 * resolution:   => invalid


Comment:

 That's not an issue in Django but in your environment. Please don't use
 Trac as a support channel. Closing per
 TicketClosingReasons/UseSupportChannels

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.0fe7ae79aa1ca663af7d4cb82a35ebd7%40djangoproject.com.

Re: [Django] #27590: Allow configuration of where to save staticfiles manifest.

[Django]

#27590: Allow configuration of where to save staticfiles manifest.
-+-
 Reporter:  David Sanders|Owner:  Jarosław
 Type:   |  Wygoda
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.staticfiles  |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Kevin Christopher Henry):

 If we take a step back, the problem here isn't that there's no way to
 configure the manifest location, it's that the standard location for it is
 bad. That's the reason people want to change it. So rather than making it
 ''possible'' for people to avoid the problem by introducing a new
 customization mechanism, we should just fix the standard value so that no
 one has the problem in the first place.

 If we accept that the default manifest location needs to change at some
 point then there will inevitably be a backwards incompatibility.

 One way to address that would be to just document in the release notes
 that people using `ManifestStaticFilesStorage` need to run `collectstatic`
 after upgrading. If they don't do that they will immediately see a helpful
 error message at startup since the manifest won't be found, and they can
 fix the problem then. Still, perhaps that's overly burdensome, I'm not
 sure.

 Another approach would be to have a deprecation cycle where `STATIC_ROOT`
 continues to be checked if the manifest isn't found at the designated
 location in the code base, showing a deprecation warning in that case.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.9b040782c89ced1f123edc33d0378929%40djangoproject.com.

Re: [Django] #32217: Add warning about missing 'migrations' package to migration docs

[Django]

#32217: Add warning about missing 'migrations' package to migration docs
-+-
 Reporter:  Tim McCurrach|Owner:  Tim
 Type:   |  McCurrach
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim McCurrach):

 * owner:  nobody => Tim McCurrach


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.188b233c879407b8ce54d97373ea4077%40djangoproject.com.

[Django] #32217: Add warning about missing 'migrations' package to migration docs

[Django]

#32217: Add warning about missing 'migrations' package to migration docs
+--
   Reporter:  Tim McCurrach |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  assigned
  Component:  Documentation |Version:  3.1
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+--
 If you create an app with no migrations folder, then running
 `makemigrations` won't make migrations for that app. This isn't really
 mentioned in the migrations doc. There is a section dedicated to apps
 where the database is already set up and migrations are missing, but
 someone who has simply created an app manually might gloss over that
 section. The only place I could actually find this written down is in a
 comment in `db.migrations.questioner` (lines 26-33).

 I have been bitten by this a few times, and only noticed my migrations
 weren't added until further on down the line when I get a database error.

 I think it would be helpful to have the above explicitly stated in the
 docs.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/056.ae9850d33e1cf8549df244691415d2e2%40djangoproject.com.

[Django] #32216: Can not execute tests with spatialite as database backend

[Django]

#32216: Can not execute tests with spatialite as database backend
---+
   Reporter:  thegreathir  |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  GIS  |Version:  3.1
   Severity:  Normal   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 I'm using django version 3.1 and  libsqlite3-mod-spatialit version
 4.3.0a-6 on ubuntu 19.10.
 My database backend is spatialite when I run tests I get following error:
 {{{
 Creating test database for alias 'default'...
 Destroying old test database for alias 'default'...
 python3: ByteOrderValues.cpp:46: static int
 geos::io::ByteOrderValues::getInt(const unsigned char*, int): Assertion
 `byteOrder == ENDIAN_LITTLE' failed.
 [1]2019 abort (core dumped)  python3 manage.py test
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/054.c336517cac7b8b047ddf3cec671704d5%40djangoproject.com.

Re: [Django] #15053: Make templates more reusable by Improving template loading algorithm to avoid extending infinite recursion

[Django]

#15053: Make templates more reusable by Improving template loading algorithm to
avoid extending infinite recursion
-+-
 Reporter:  Pablo Martín |Owner:  Unai
 |  Zalakain
 Type:  New feature  |   Status:  closed
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"c70cd2a926ffab47f6613e83e0c8828eb6c2c064" c70cd2a9]:
 {{{
 #!CommitTicketReference repository=""
 revision="c70cd2a926ffab47f6613e83e0c8828eb6c2c064"
 Refs #15053 -- Clarified debug message when skipping templates to avoid
 recursion.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.56330786dae3f1833320ecda265e47bf%40djangoproject.com.

Re: [Django] #28041: Postgres prefix searching for full text search

[Django]

#28041: Postgres prefix searching for full text search
--+---
 Reporter:  Joe Tsoi  |Owner:  Karl Hobley
 Type:  New feature   |   Status:  assigned
Component:  contrib.postgres  |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+---
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.fc887921638fb84c950f347b7724%40djangoproject.com.