Re: DKIM signing option for stmp.MailBackend?

[Claude Paroz]

Le vendredi 3 avril 2015 19:05:02 UTC+2, Loek van Gent a écrit :
>
> Hi all,
>
> Is anyone using DKIM signing for densing emails? Does it make sense to you 
> to have a feature like that in Django core or is this typically something 
> that should be in it's own app?
>

I think that generally DKIM is most often a task of the MTA (mail transfer 
agent), while Django is playing the role of the MUA (user agent) here. 
Hence I wouldn't push for a Django core integration, but more as an 
external add-on.

Claude

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/21692a8d-f5c3-4389-83a5-b7fdb4c445d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DKIM signing option for stmp.MailBackend?

[Bruno Ribeiro da Silva]

I do think DKIM is a task for the MTA too, so it doesn't make much sense to
have it in django's core.
On Apr 4, 2015 6:27 AM, "Claude Paroz"  wrote:

> Le vendredi 3 avril 2015 19:05:02 UTC+2, Loek van Gent a écrit :
>>
>> Hi all,
>>
>> Is anyone using DKIM signing for densing emails? Does it make sense to
>> you to have a feature like that in Django core or is this typically
>> something that should be in it's own app?
>>
>
> I think that generally DKIM is most often a task of the MTA (mail transfer
> agent), while Django is playing the role of the MUA (user agent) here.
> Hence I wouldn't push for a Django core integration, but more as an
> external add-on.
>
> Claude
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/21692a8d-f5c3-4389-83a5-b7fdb4c445d5%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAE-2%3DJztAorZA6yNa4ZsWvhMUEovZ%3DW5_9SoiQGueLU%2Bvdb%2BdA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Tim Graham]

Now that Django 1.8 is released, I wanted to bump this thread for 
discussion so we can hopefully ratify this schedule or modify it based on 
feedback. In particular, I heard a concern that a six month release 
schedule may be too often for the community. On the other hand, I think 
smaller releases would make incremental upgrades easier.

One difficulty could be if third-party packages try to support every 
version since the last LTS (this seemed to be common with 1.4). A 6 month 
release schedule would mean 5 versions of Django until the next LTS, 
instead of 3 as we had since 1.4, so more `if DJANGO_X_Y` conditionals. One 
idea is that third-party packages could declare their own "LTS" versions 
(if needed) and drop support for older versions more freely in future 
development.

On Wednesday, March 11, 2015 at 8:13:11 PM UTC-4, Tim Graham wrote:
>
> With the release of 1.8 coming up, it's time to think about 1.9! I've 
> suggested some dates below. The schedule is similar to the intervals we 
> used for 1.8 with the final release date planned for about 6 months after 
> 1.8 final (barring unforeseen delays, 1.8 will be released about 7 months 
> after 1.7). Please voice any thoughts or concerns. With this schedule it 
> seems that any GSoC work would likely be included in 2.0. If you have any 
> big features planned, please add them here: 
> https://code.djangoproject.com/wiki/Version1.9Roadmap
>
> July 20 - Alpha (feature freeze)
> August 21 - Beta (only release blockers fixed after this)
> September 18 - RC (string freeze for translations)
> October 2 - Final
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0df00068-112f-4e98-9201-78d6ba9ef97c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Thorsten Sanders]

Am 04.04.2015 14:30, schrieb Tim Graham:
Now that Django 1.8 is released, I wanted to bump this thread for 
discussion so we can hopefully ratify this schedule or modify it based 
on feedback. In particular, I heard a concern that a six month release 
schedule may be too often for the community. On the other hand, I 
think smaller releases would make incremental upgrades easier.
I started to use django years ago and I like it but these fast releases 
result in quite some projects running django version not getting any 
security fixes anymore, yes there is the LTS but if I start a new 
project I use the current version to get features not being in the LTS 
version and I dont have the time to upgrade all projects to the current 
and do in depth testing if all works like expected and such a fast 
release cycle makes it even worse, if there is such an fast release 
cycle at least older version should get security fixes too otherwise its 
kinda unattractive to use it.




One difficulty could be if third-party packages try to support every 
version since the last LTS (this seemed to be common with 1.4). A 6 
month release schedule would mean 5 versions of Django until the next 
LTS, instead of 3 as we had since 1.4, so more `if DJANGO_X_Y` 
conditionals. One idea is that third-party packages could declare 
their own "LTS" versions (if needed) and drop support for older 
versions more freely in future development.


On Wednesday, March 11, 2015 at 8:13:11 PM UTC-4, Tim Graham wrote:

With the release of 1.8 coming up, it's time to think about 1.9!
I've suggested some dates below. The schedule is similar to the
intervals we used for 1.8 with the final release date planned for
about 6 months after 1.8 final (barring unforeseen delays, 1.8
will be released about 7 months after 1.7). Please voice any
thoughts or concerns. With this schedule it seems that any GSoC
work would likely be included in 2.0. If you have any big features
planned, please add them here:
https://code.djangoproject.com/wiki/Version1.9Roadmap


July 20 - Alpha (feature freeze)
August 21 - Beta (only release blockers fixed after this)
September 18 - RC (string freeze for translations)
October 2 - Final

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0df00068-112f-4e98-9201-78d6ba9ef97c%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/551FDF14.2080908%40gmx.net.
For more options, visit https://groups.google.com/d/optout.

Re: DKIM signing option for stmp.MailBackend?

[Alex Gaynor]

I agree that DKIM is the responsibility of an MTA, not Django.

Alex

On Sat, Apr 4, 2015 at 6:53 AM, Bruno Ribeiro da Silva <
bruno.dev...@gmail.com> wrote:

> I do think DKIM is a task for the MTA too, so it doesn't make much sense
> to have it in django's core.
> On Apr 4, 2015 6:27 AM, "Claude Paroz"  wrote:
>
>> Le vendredi 3 avril 2015 19:05:02 UTC+2, Loek van Gent a écrit :
>>>
>>> Hi all,
>>>
>>> Is anyone using DKIM signing for densing emails? Does it make sense to
>>> you to have a feature like that in Django core or is this typically
>>> something that should be in it's own app?
>>>
>>
>> I think that generally DKIM is most often a task of the MTA (mail
>> transfer agent), while Django is playing the role of the MUA (user agent)
>> here. Hence I wouldn't push for a Django core integration, but more as an
>> external add-on.
>>
>> Claude
>>
>> --
>> 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/21692a8d-f5c3-4389-83a5-b7fdb4c445d5%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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAE-2%3DJztAorZA6yNa4ZsWvhMUEovZ%3DW5_9SoiQGueLU%2Bvdb%2BdA%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFRnB2VneJ_JeJVwgekKe%2BQ-v-sUtMsUFr7SF1m1OoNb4xa83Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Thomas Tanner]

I think rare LTS releases and frequent (6month) incremental upgrades are
a good compromise.
Third-party packages should support LTS releases and at least the latest
Django version. They may drop support for earlier non-LTS releases.
Either you stick with the LTS release or you go with the cutting edge
with all dependencies.

Advantages of release early, release often are that new features have
more time to mature before a LTS release, you don't have to risk using
the unstable HEAD for new features, and more feedback from users.

On 04.04.15 14:30, Tim Graham wrote:
> Now that Django 1.8 is released, I wanted to bump this thread for
> discussion so we can hopefully ratify this schedule or modify it based
> on feedback. In particular, I heard a concern that a six month release
> schedule may be too often for the community. On the other hand, I think
> smaller releases would make incremental upgrades easier.
> 
> One difficulty could be if third-party packages try to support every
> version since the last LTS (this seemed to be common with 1.4). A 6
> month release schedule would mean 5 versions of Django until the next
> LTS, instead of 3 as we had since 1.4, so more `if DJANGO_X_Y`
> conditionals. One idea is that third-party packages could declare their
> own "LTS" versions (if needed) and drop support for older versions more
> freely in future development.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/552017D7.6020907%40gmx.net.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Michael Manfre]

On Sat, Apr 4, 2015 at 12:56 PM, Thomas Tanner  wrote:

> I think rare LTS releases and frequent (6month) incremental upgrades are
> a good compromise.
> Third-party packages should support LTS releases and at least the latest
> Django version. They may drop support for earlier non-LTS releases.
> Either you stick with the LTS release or you go with the cutting edge
> with all dependencies.
>

I'm not advocating for or against more frequent releases, but trying to
impose a support policy upon 3rd party packages is not going to work. It
would great if they support whatever versions of Django are still
supported, but sometimes that takes more time/effort than the maintainer is
willing to devote.

The number or frequency of releases doesn't matter as much as the content
of the releases. Depending on the app, some Django versions are harder to
support at the same time. The back-to-back major changes to the Datatbase
API forced django-mssql to only support a single Django version with each
release. After that change, I was less inclined to backport fixes and even
stopped testing against Django 1.4 well before it was out of support.



> Advantages of release early, release often are that new features have
> more time to mature before a LTS release, you don't have to risk using
> the unstable HEAD for new features, and more feedback from users.
>
> On 04.04.15 14:30, Tim Graham wrote:
> > Now that Django 1.8 is released, I wanted to bump this thread for
> > discussion so we can hopefully ratify this schedule or modify it based
> > on feedback. In particular, I heard a concern that a six month release
> > schedule may be too often for the community. On the other hand, I think
> > smaller releases would make incremental upgrades easier.
> >
> > One difficulty could be if third-party packages try to support every
> > version since the last LTS (this seemed to be common with 1.4). A 6
> > month release schedule would mean 5 versions of Django until the next
> > LTS, instead of 3 as we had since 1.4, so more `if DJANGO_X_Y`
> > conditionals. One idea is that third-party packages could declare their
> > own "LTS" versions (if needed) and drop support for older versions more
> > freely in future development.
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/552017D7.6020907%40gmx.net
> .
> 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAGdCwBvxx%3DVKUscGQV1v%3DezeRkJVY4VJzDBZd9OaJ5SF9951oA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Shai Berger]

On Saturday 04 April 2015 21:16:54 Michael Manfre wrote:
> On Sat, Apr 4, 2015 at 12:56 PM, Thomas Tanner  wrote:
> > I think rare LTS releases and frequent (6month) incremental upgrades are
> > a good compromise.
> > Third-party packages should support LTS releases and at least the latest
> > Django version. They may drop support for earlier non-LTS releases.
> > Either you stick with the LTS release or you go with the cutting edge
> > with all dependencies.
> 
> I'm not advocating for or against more frequent releases, but trying to
> impose a support policy upon 3rd party packages is not going to work. 

I agree fully.


> The number or frequency of releases doesn't matter as much as the content
> of the releases.

Here I disagree. For our more corporate-oriented users, version upgrades are a 
beaurocratic hassle as well as a technical one. But also on the technical 
level, each version upgrade has overhead in testing and validation; and 
sometimes, for full-project products just as much as for 3rd-party apps, the 
problems of supporting multiple versions at once.

The clients I've worked with were having a hard time keeping up as it was.

Shai.

Re: django-admin.py shebang

[frantisek holop]

Stan, 01 Apr 2015 04:46:
> Hi devs,
> 
> Is there a good reason for having the shebang line in django-admin.py at 
> #!/usr/bin/python
> "instead" of #!/usr/bin/env python ?

is there a good reason to use the latter?

"env python" is a terrible hack for systems that
are way behind with their "official" packages.
it creates a nightmare when multiple python
versions are installed.

when outside virtualenv, i prefer the first
version exactly for the same reason you
prefer the latter: so that the interpreter
used is deterministic -- the system one --
instead of who knows what that could be picked
up from the user's PATH...

it is the same reason why the current path ('.')
should be the last element of PATH: so that
a local executable named after an existing
system-wide program is not shadowing it, creating
potentially difficult to track down problems.
"explicit is better than implicit", right?

if you want to override the path to the interpreter,
put it on the command line.  otherwise a simple
change in PATH could break the whole application.

-f
-- 
xerox never comes up with something original.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20150404233717.GU5382%40obiit.org.
For more options, visit https://groups.google.com/d/optout.

Fellow Report - April 3, 2015

[Tim Graham]

During the first half of the week I assisted with a couple of final bugs in 
1.8. I also did some other release preparation tasks, like updating the 
djangoproject.com downloads page (which is mostly programatically 
generated) to accommodate two supported LTS versions (otherwise 1.4 would 
have appeared as “unsupported” upon the release of 1.8).

Later in the week I spent some time on other djangoproject.com issues. I 
helped Jannis Leidel rollout Elasticsearch integration for the 
documentation search page and reviewed/merged Michael Trythall’s work to 
switch the website’s SCSS compilation to libsass. The latter allowed us to 
remove the compiled CSS files from the repository and instead compile it on 
the server which should help prevent merge conflicts. I added a new 
“Supported Versions” sections to the download page 
 to give a better overview of which 
Django versions are supported and for how long.

We’ve already merged 3 bug fixes to be released in 1.8.1. I plan to release 
that version by May 1, perhaps sooner if we accumulate a lot of fixes in 
the meantime.

Report for week ending April 3, 2015:

Triaged

---

https://code.djangoproject.com/ticket/24565 - server_default option on 
model fields (duplicate)

https://code.djangoproject.com/ticket/24566 -MigrationWriter doesn't 
serialize timedelta (accepted) 

https://code.djangoproject.com/ticket/24567 - /admin/auth/user/add/ 
requires "auth | user | Can change user" (invalid)

https://code.djangoproject.com/ticket/24574 - 'python manage.py runserver' 
sleeps forever because of threading lock (needsinfo)

https://code.djangoproject.com/ticket/24576 - Bad cascading leads to 
non-deterministic IntegrityError (accepted)

https://code.djangoproject.com/ticket/24575 - Add an option to 
smtp.EmailBackend for DKIM signing (won’t fix)

https://code.djangoproject.com/ticket/24578 - prepare_database_save breaks 
some OneToOneField's in 1.8 (accepted)

Authored



https://github.com/django/djangoproject.com/pull/421 - Added support for 
two supported LTS versions to the downloads page.

https://github.com/django/djangoproject.com/pull/424 - Fixed #390 -- Added 
release notes links to download page.

https://github.com/django/djangoproject.com/pull/428 - Added a "Supported 
Versions" table to the downloads page.

https://github.com/django/django/pull/4411 - Fixed sessions test on Python 
3.5.

Reviewed/committed

--

https://github.com/django/django/pull/4406 - Fixed #15590 -- Documented how 
the path of a FileField can be changed.

https://github.com/django/django/pull/4409 - Fixed #24556 -- Added reminder 
about HTTPS to passwords docs.

https://github.com/django/django/pull/4105 - Fixed #24301 -- Added 
PostgreSQL-specific aggregate functions

https://github.com/django/django/pull/4424 - Fixed behavior of 
InclusionNode.

https://github.com/django/djangoproject.com/pull/420 - Switched to Libsass 
for CSS compilation.

https://github.com/django/djangoproject.com/pull/303 - Switched search to 
Elasticsearch

https://github.com/django/djangoproject.com/pull/430 - Switched to watchdog 
for recursive CSS watching.

https://github.com/django/djangoproject.com/pull/432 - Ensured icons flip 
when they are in view.

https://github.com/django/djangoproject.com/pull/413 - Gray out unpublished 
blog entry summaries.

Reviews of core dev work



https://github.com/django/django/pull/4408 - Fixed #24550 -- Added 
migration operation description to sqlmigrate output

https://github.com/django/django/pull/ - Fixed #24571 -- Restored 
testserver positional arguments parsing

https://github.com/django/django/pull/4445 - Fixed #24569 -- Made some 
translation functions accept None value

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/305fffaf-1940-4e26-8731-703896dbdfda%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.