Re: disclosing security release dates on django-announce
On Friday 07 October 2016 19:47:38 Markus Holtermann wrote: > On Friday, October 7, 2016 at 4:58:00 PM UTC+2, Tim Graham wrote: > > The Django team proposes [0] to add the following to the security policy: > > > > Approximately one week before public disclosure, ... > > we notify django-announce [1] of the date and approximate time of the > > upcoming security release. No information about the issues is given. [...] > > While we haven't decided of any particular format, you can expect the > announcements to look a bit like >https://mta.openssl.org/pipermail/openssl-announce/2016-September/76.html > with nitpicking(): this example does give some information about the issues -- the number of issues and an assessment of their severitly level. I believe it is a good example to follow. Shai.
Fellow Report - October 8, 2016
Triaged --- https://code.djangoproject.com/ticket/27304 - Django 1.10 onwards broke previous behaviour for models.DateTimeField() in Admin (invalid) https://code.djangoproject.com/ticket/27258 - Raise an exception if RequestContext is used with template.backends.django.Template.render() (accepted) https://code.djangoproject.com/ticket/27295 - Add a system check to prohibit models that start with an underscore (accepted) https://code.djangoproject.com/ticket/27308 - BytesWarning exception raised when running with python 3 -bb option (accepted) https://code.djangoproject.com/ticket/27313 - Allow overriding the admin's popup response template on an app or model basis (accepted) https://code.djangoproject.com/ticket/27312 - Checking raw argument to prevent signals from executing during fixture loading isn't DRY (needsinfo) https://code.djangoproject.com/ticket/27319 - Circular ForeignKeys between two unmanaged models produce incomplete migrations (accepted) https://code.djangoproject.com/ticket/27315 - IntegrityError: insert or update on table violates foreign key constraint on Django 1.10 (needsinfo) https://code.djangoproject.com/ticket/27317 - Make Form subclasses combine Form.Media from all parents (accepted) https://code.djangoproject.com/ticket/27326 - Overriding queryset deletion from ModelAdmin (duplicate) Authored https://github.com/django/django/pull/7360 - Fixed #27148 -- Fixed ModelMultipleChoiceField crash with invalid UUID. https://github.com/django/django/pull/7361 - Fixed #27327 -- Simplified time zone handling by requiring pytz. Reviewed/committed -- https://github.com/django/djangoproject.com/pull/709 - Fixed #551 -- Prevented a hero from being created on a failed donation. https://github.com/django/django/pull/7337 - Fixed #27309 -- Added CallableBool.__hash__(). https://github.com/django/django/pull/7338 - Refs #27118 -- Reallowed using pk in QuerySet.get/update_or_create(). https://github.com/django/django/pull/7319 - Fixed #27193 -- Preserved ordering in select_for_update subqueries. https://github.com/django/django/pull/7330 - Fixed #27218 -- Returned LogEntry instances from ModelAdmin.log_*() methods. https://github.com/django/django/pull/7332 - Fixed #27262 -- Moved URL checks to resolver and pattern classes. https://github.com/django/django/pull/7325 - Fixed #27301 -- Prevented exceptions that fail unpickling from crashing the parallel test runner. https://github.com/django/django/pull/7335 - Fixed #26327 -- Added JsonAgg to contrib.postgres. https://github.com/django/django/pull/7252 - Fixed #24941 -- Added ModelAdmin.get_exclude(). Reviews of core dev work https://github.com/django/django/pull/7336 - Fixed #27279 -- Fixed a migration performance regression related to RenameModel operations. -- 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/c125a808-72a8-4619-a0ec-b73fd1361a23%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Should we require pytz for timezone support in Django?
I created a ticket and PR to add pytz to install_requires. I think it's a nice simplification and will result in a better user experience. https://code.djangoproject.com/ticket/27327 https://github.com/django/django/pull/7361 On Monday, June 6, 2016 at 5:28:11 AM UTC-4, Aymeric Augustin wrote: > > > On 06 Jun 2016, at 03:46, Carl Meyer > > wrote: > > > >> django-admin.py startproject defaults to USE_TZ = True which means that > new projects that install django, start the project, and then run the > internal web server are going to get missing dependency problems. > > > > That's an excellent point. I agree, we should just add pytz to > install_requires if we require it for USE_TZ=True, otherwise the default > new-project experience is unpleasant. > > I agree as well. > > One of these days we should reverse the “actual default value” so we don’t > have to override it in the “default project template” (and then people > obviously have no idea what the “default” is…) > > -- > Aymeric. > > -- 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/5c96fb2e-a620-4a1a-a584-64c3318f9837%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.