Re: Fellow Report - October 31, 2014

[Justin Myles Holmes]

Tim,

Yes I see.  This is great.  I agree with your assessments in full.


On 10/31/2014 06:19 PM, Tim Graham wrote:
> Hi Justin,
>
> Thanks for the feedback. Making 1.8 the next LTS was discussed a bit
> internally before I shared the idea and tentative schedule for the 1.8
> release on the thread "1.8 release planning." The only feedback on
> that thread (2 weeks ago) was from Josh Smeaton who supported the
> details outlined there. There is still time to weigh in there if you like.
>
> Tim
>
> On Friday, October 31, 2014 8:28:26 PM UTC-4, Justin Holmes wrote:
>
> Tim,
>
> This truly is a stellar report.  Thanks so much.
>
> I do have one question about this statement:
>
> > A reminder that we expect Django 1.8 to become the next LTS
> version of
> Django, so if you have a pet bug or feature, now's a great time to
> get
> it fixed!
>
> You characterize this as a "reminder" - I didn't realize this had
> been
> firmly decided, although it was obviously discussed at DjangoCon.
> Although I'm definitely in support, I am curious: who made this
> decision
> and when?
>
>
> On 10/31/2014 04:04 PM, Tim Graham wrote:
> >
> > To briefly summarize the triage and review work, we continue to
> > retrieve good bug reports for Django 1.7, particularly migration
> edge
> > cases. I'd expect to see another bug fix release for the 1.7 series
> > within a month of 1.7.1. One issue the core team will be
> addressing at
> > the "Django: Under the Hood" conference in mid-November is
> adding more
> > team members to the list of people who can release Django. The
> lack of
> > availability of someone who has the time and privileges to do a
> > release has been a bottleneck on occasion. In addition to bug
> fixing
> > on the 1.7 branch, master (1.8) continues to receive a steady
> diet of
> > new small features. A reminder that we expect Django 1.8 to
> become the
> > next LTS version of Django, so if you have a pet bug or feature,
> now's
> > a great time to get it fixed!
>
> -- 
> 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/98ff9e20-5bc9-474a-aef0-538b1b479aa7%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/54543B54.1080004%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fellow Report - October 31, 2014

[Tim Graham]

Hi Justin,

Thanks for the feedback. Making 1.8 the next LTS was discussed a bit 
internally before I shared the idea and tentative schedule for the 1.8 
release on the thread "1.8 release planning." The only feedback on that 
thread (2 weeks ago) was from Josh Smeaton who supported the details 
outlined there. There is still time to weigh in there if you like.

Tim

On Friday, October 31, 2014 8:28:26 PM UTC-4, Justin Holmes wrote:
>
> Tim, 
>
> This truly is a stellar report.  Thanks so much. 
>
> I do have one question about this statement: 
>
> > A reminder that we expect Django 1.8 to become the next LTS version of 
> Django, so if you have a pet bug or feature, now's a great time to get 
> it fixed! 
>
> You characterize this as a "reminder" - I didn't realize this had been 
> firmly decided, although it was obviously discussed at DjangoCon. 
> Although I'm definitely in support, I am curious: who made this decision 
> and when? 
>
>
> On 10/31/2014 04:04 PM, Tim Graham wrote: 
> > 
> > To briefly summarize the triage and review work, we continue to 
> > retrieve good bug reports for Django 1.7, particularly migration edge 
> > cases. I'd expect to see another bug fix release for the 1.7 series 
> > within a month of 1.7.1. One issue the core team will be addressing at 
> > the "Django: Under the Hood" conference in mid-November is adding more 
> > team members to the list of people who can release Django. The lack of 
> > availability of someone who has the time and privileges to do a 
> > release has been a bottleneck on occasion. In addition to bug fixing 
> > on the 1.7 branch, master (1.8) continues to receive a steady diet of 
> > new small features. A reminder that we expect Django 1.8 to become the 
> > next LTS version of Django, so if you have a pet bug or feature, now's 
> > a great time to get it fixed! 
>
>

-- 
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/98ff9e20-5bc9-474a-aef0-538b1b479aa7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fellow Report - October 31, 2014

[Justin Myles Holmes]

Tim,

This truly is a stellar report.  Thanks so much.

I do have one question about this statement:

> A reminder that we expect Django 1.8 to become the next LTS version of
Django, so if you have a pet bug or feature, now's a great time to get
it fixed!

You characterize this as a "reminder" - I didn't realize this had been
firmly decided, although it was obviously discussed at DjangoCon. 
Although I'm definitely in support, I am curious: who made this decision
and when?


On 10/31/2014 04:04 PM, Tim Graham wrote:
>
> To briefly summarize the triage and review work, we continue to
> retrieve good bug reports for Django 1.7, particularly migration edge
> cases. I'd expect to see another bug fix release for the 1.7 series
> within a month of 1.7.1. One issue the core team will be addressing at
> the "Django: Under the Hood" conference in mid-November is adding more
> team members to the list of people who can release Django. The lack of
> availability of someone who has the time and privileges to do a
> release has been a bottleneck on occasion. In addition to bug fixing
> on the 1.7 branch, master (1.8) continues to receive a steady diet of
> new small features. A reminder that we expect Django 1.8 to become the
> next LTS version of Django, so if you have a pet bug or feature, now's
> a great time to get it fixed!

-- 
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/54542921.2040007%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report - October 31, 2014

[Tim Graham]

Hello,

If you've read the djangoproject.com blog, you know that Berker Peksag and 
I have been appointed as "Django Fellows" during the three month pilot 
program. Part of those duties (which started this week) is to provide a 
weekly summary of our activities to this mailing list. That report follows.

Also, I wanted to mention that part of the purpose of the fellowship 
program is to provide resources to review code, as that is clearly a 
bottleneck in our contribution process. If you have tried contributing 
before and your patch languished without review, I'd encourage you to reach 
out and try again. While I am not an expert in all areas of Django, I will 
do my beast to try to help you find someone to review your work if I can't 
do so myself. Though I'll remind you that *anyone* in the Django community 
is welcome to review patches and mark them as "ready for checkin", not just 
core developers. Reviewing patches is a big help and a great way to earn 
the trust of the team. If you have any feedback on my work, feel free to 
leave it here or contact me privately.

Thanks for your support of the Django Software Foundation, which makes this 
program possible!
Tim


Report for week ending October 31, 2014:

In addition to the triage and review work listed below, I updated the 
Ansible playbooks for Jenkins to run on Ubuntu 14.04 so that we can have a 
continuous integration server with some newer database versions. (These 
playbooks need some minor adjustments so as not to reveal passwords before 
they can be made public.) Upon running Django's test suite on the new 
machine, I discovered a couple unexpected test failures:

1. 37 test failures with Python 3.2.6. I investigated the failures and 
created a ticket in the Python tracker that outlines the issue: 
http://bugs.python.org/issue22758. Corresponding with a Python core 
developers in that ticket, I learned that the fix for Python's "lax cookie 
parsing" issue was incomplete and that when it's fixed properly, Django 
likely won't be compatible with the fixed versions of Python! This affects 
the Python 2.7 and 3.2+ branches. The remedy for Django (which is altering 
our workaround for a bug in Python) is outlined in 
https://code.djangoproject.com/ticket/23730. I created a ticket and 
submitted a patch to fix the issue in Python itself so we can eventually 
remove our workaround in Django: http://bugs.python.org/issue22775.

2. A migrations GIS test failure revealed an incompatibility with MySQL 
5.6+. I authored a fix for this issue as outlined in 
https://code.djangoproject.com/ticket/23719.

3. There are a couple of test failures with the version of SpatiaLite (4.1) 
that's included with Ubuntu 14.04 that I still need to investigate and 
ticket as necessary.

To briefly summarize the triage and review work, we continue to retrieve 
good bug reports for Django 1.7, particularly migration edge cases. I'd 
expect to see another bug fix release for the 1.7 series within a month of 
1.7.1. One issue the core team will be addressing at the "Django: Under the 
Hood" conference in mid-November is adding more team members to the list of 
people who can release Django. The lack of availability of someone who has 
the time and privileges to do a release has been a bottleneck on occasion. 
In addition to bug fixing on the 1.7 branch, master (1.8) continues to 
receive a steady diet of new small features. A reminder that we expect 
Django 1.8 to become the next LTS version of Django, so if you have a pet 
bug or feature, now's a great time to get it fixed!

Triaged
---
https://code.djangoproject.com/ticket/23681 - Document how to customize 
NullBooleanSelect choice names (accepted)
https://code.djangoproject.com/ticket/23720 - Login redirect should be 
glued to schema (invalid)
https://code.djangoproject.com/ticket/23725 - Inconsistent documentation 
about ForeignKey(User) (accepted)
https://code.djangoproject.com/ticket/23724 - Add overwrite mode to 
collectstatic (won't fix)
https://code.djangoproject.com/ticket/23729 - Small error in documentation 
(invalid)
https://code.djangoproject.com/ticket/23706 - Accessing related object of 
object from not default DB, queries default DB (needs info)
https://code.djangoproject.com/ticket/23718 - TEST_MIRROR setting doesn't 
work as expected (and has no tests) (accepted)
https://code.djangoproject.com/ticket/23727 - IntegrityError with 
TransactionTestCase and sqlite (accepted)
https://code.djangoproject.com/ticket/23734 - Templates intro talks about 
striptags without the appropriate security disclaimer (fixed)
https://code.djangoproject.com/ticket/23735 - Templates intro shouldn't 
assume admindocs is enabled (fixed)
https://code.djangoproject.com/ticket/23736 - Description of 
silent_variable_failure is incorrect (fixed)
https://code.djangoproject.com/ticket/23737 - RequestContext docs should 
recommend the render shortcut more clearly (fixed)
https://code.djangoproject.com/ticket/23739 - django 1.7.1 

Re: Setting database default values in migrations (postgres)

[Jon Dufresne]

On Fri, Oct 31, 2014 at 9:46 AM, Andrew Godwin  wrote:
> So, bear in mind that you can easily set these defaults yourself in a
> migration with RunSQL if you need them for legacy purposes; that way they'll
> get applied

Absolutely. I effectively have such a system in place at the moment.

But, my point is I am also making an effort to match Django's expected
schema while moving away from the legacy schema. I would prefer not to
drift too far from Django's expectations as the goal is move entirely
to Django. This is just one more thing to keep track of and handle
semi-manually.

All I'm saying is that if the described feature existed, it would
benefit me and others that share my use case.

-- 
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/CADhq2b7zb4SfwTpE8AvuaCkuNLVO%3DYQoFNQZK3ks6fpR0%3DjVYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Setting database default values in migrations (postgres)

[Andrew Godwin]

So, bear in mind that you can easily set these defaults yourself in a
migration with RunSQL if you need them for legacy purposes; that way
they'll get applied, we don't need to add more code to Django, and it works
fine for simple plain defaults without the need for a system where Django
tries to work out if the default is safe or not.

Andrew

On Fri, Oct 31, 2014 at 9:35 AM, Jon Dufresne 
wrote:

> On Fri, Oct 31, 2014 at 6:48 AM, Shai Berger  wrote:
> > Peter, you said you're "interested in getting database migrations to
> support
> > setting database-level default values", but you haven't said why; unless
> > there's a convincing use-case, I'm going to be -1 on this (per the new
> rules,
> > this is no longer a veto, but still).
>
> I am not the original poster, but, FWIW, I too would benefit from this
> feature.
>
> My Django application interacts with an existing Legacy application
> and database. These two applications share the existing database.
> Parts of the Legacy application have been ported to Django, other
> parts haven't. The existing Legacy application and legacy scripts
> relied on these database defaults to handle some data. I've made an
> effort to shape the database and Legacy application to the "Django
> way", but sometimes it is inconvenient given the existing Legacy
> compatibility.
>
> For my particular use case, just handling "primitave" values would be
> sufficient: True, False, numbers, text. I understand arbitrary Python
> functions can't be easily represeted by databases in a cross platform
> way, but that is already beyond the common case. Those functions would
> need to be implemented by the Legacy application already.
>
> As far as I'm concerned, Django's ORM doesn't even need to rely on
> these defaults when creating objects, but if the migration system
> _created_ them (and kept them up to date) it would be very helpful to
> people in my situation.
>
> Cheers,
> Jon
>
> --
> 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/CADhq2b7wNsZfoY9Gnq2QejigOCCO08uzQtmo7ZK8AX1whHnSRg%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFwN1uo4Na6VrCSJzsd9g-6Kieg9nVyxJbuyvRG6UjKuM_zTtw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Setting database default values in migrations (postgres)

[Jon Dufresne]

On Fri, Oct 31, 2014 at 6:48 AM, Shai Berger  wrote:
> Peter, you said you're "interested in getting database migrations to support
> setting database-level default values", but you haven't said why; unless
> there's a convincing use-case, I'm going to be -1 on this (per the new rules,
> this is no longer a veto, but still).

I am not the original poster, but, FWIW, I too would benefit from this feature.

My Django application interacts with an existing Legacy application
and database. These two applications share the existing database.
Parts of the Legacy application have been ported to Django, other
parts haven't. The existing Legacy application and legacy scripts
relied on these database defaults to handle some data. I've made an
effort to shape the database and Legacy application to the "Django
way", but sometimes it is inconvenient given the existing Legacy
compatibility.

For my particular use case, just handling "primitave" values would be
sufficient: True, False, numbers, text. I understand arbitrary Python
functions can't be easily represeted by databases in a cross platform
way, but that is already beyond the common case. Those functions would
need to be implemented by the Legacy application already.

As far as I'm concerned, Django's ORM doesn't even need to rely on
these defaults when creating objects, but if the migration system
_created_ them (and kept them up to date) it would be very helpful to
people in my situation.

Cheers,
Jon

-- 
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/CADhq2b7wNsZfoY9Gnq2QejigOCCO08uzQtmo7ZK8AX1whHnSRg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Django's problem with db-level defaults on Oracle

[Shai Berger]

Hi Everyone,

I just mentioned in another thread that db-level defaults are particularly 
troublesome on Oracle. I didn't want to burden that discussion with the 
detais, but having been asked about it on IRC (thanks Josh), here they are.

The problem is caused by a combination of factors:

1) Oracle stores database-level defaults as strings, evaluated when needed.

This is not, in itself, completely insensible -- the processing and space 
overheads (compared to some more "binary" representation) are negligible, and 
it means defaults "4" and "sysdate()" are treated by the system uniformly.

2) Django's Oracle backend sets the date-time format to a constant (close to 
ISO format), which is usually not the default.

This has been used to perform some database date-time operations by 
manipulating strings -- because that way was easier to the developer 
implementing them, or there wasn't proper support for the feature otherwise; 
as a classic example, before 1.7, date-times used to be inserted into the 
database as strings, because some special manipulation was required to make 
cx_Oracle (the database driver library) support sub-second precision (thanks 
jtiai). I'm not completely sure how much date-string-manipulation remains in 
the Oracle backend today, but it is certainly still used for database 
defaults: Oracle doesn't take parameters in DDL statements.

As a result of these two factors, when datetimes were set as default column 
values (which happened a lot with South<0.7.3), the value actually stored in 
the schema was a string specifying the date-time in a non-default format. 
Whenever Django connected to the DB, it set the session's date-time format to 
the "right" one, and so no problems were seen.

But when backing up using the oracle "exp" utility -- which, as far as I'm 
aware, is pretty standard, at least as a developer backing up schemas on their 
own instance -- it was still these strings that were saved; and when trying to 
restore with the converse "imp", whose connection is (of course) not 
controlled by Django, the utility tried to set the date-time defaults by a 
format that was inappropriate for the values. This usually failed, resulting 
in partial restores, which lead to a lot of pain.

If you're still here, you probably want to know how we solved the problem: Our 
DBA showed us how to install a database-level trigger to change the format 
whenever the relevant users logged on. This allowed us to get Oracle's "imp" 
to use the right date-time formats. However, this is highly non-obvious: I, 
for one, didn't even know such triggers existed.

Thanks for your attention,

Shai.

-- 
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/201410311734.08971.shai%40platonix.com.
For more options, visit https://groups.google.com/d/optout.

Re: Setting database default values in migrations (postgres)

[Shai Berger]

On Thursday 30 October 2014 23:00:18 Andrew Godwin wrote:
> 
> If this does happen, I'd probably want some way to declare what defaults to
> keep. (South actually used to have this with a keep_default option on the
> add_column method but it was kind of unmaintained)
> 
IIRC, in the few South releases between 0.7.3 and 0.8.2 we killed the 
functionality, and only kept accepting the parameters to avoid breakage of old 
migrations.

Defaults-in-the-DB may be OK on Postgres (I'm not fluent enough in it to tell), 
but they lead to very odd problems on Oracle, e.g, requiring special, non-
obvious actions in order to make backups possible. I'm really not sure about 
the other backends; and I think the behavior in this respect should be uniform 
across backends (and welcoming to 3rd-party backends as well).

Peter, you said you're "interested in getting database migrations to support 
setting database-level default values", but you haven't said why; unless 
there's a convincing use-case, I'm going to be -1 on this (per the new rules, 
this is no longer a veto, but still).

I would be much less opposed to a specific default-setting operation in 
migrations -- that is, allowing users to explicitly set db-level defaults if 
they really want to; my main concern is with the automatic translation of a 
model-level default to a database-level one.

Shai.

-- 
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/201410311548.15207.shai%40platonix.com.
For more options, visit https://groups.google.com/d/optout.

Re: sys.exit(1) from makemigrations if no changes found

[Luke Plant]

My preference for this would be option 3., on the grounds that:

* I'd rule out 1 because of the slight backwards incompatibility (which
can affect people - I remember a deploy script failing because of a
changed exit code for a Mercurial command). In particular, currently
there are other conditions when you get a non-zero exit code - for the
case of some crash due to incorrect setup or other runtime error. This
is a distinct case from  "this command errored because there were no
migrations to make".

* I'd rule out 2 because it really makes --dry-run behave differently
from normal, which breaks expectations

Basically, having a flag like "--exit" is nice and explicit.

Luke

On 29/10/14 01:22, Tim Heap wrote:
> Hi all,
> 
> I have created a ticket for this
> (https://code.djangoproject.com/ticket/23728) but I would like some
> input before I work on it. I will copy the content of the ticket below
> for ease of reading:
> 
> It would be very useful for continuous deployment, testing, commit
> hooks, and other applications if django-admin makemigrations signaled
> via an exit code if any migrations were found. Commits in projects could
> be rejected if migrations were outstanding, continuous deployment
> systems could fail the build on outstanding migrations, and potentially
> other uses. No more would hasty commits break things when developers
> forgot to make migrations!
> 
> Changes to the code to make this happen are easy enough, but I am unsure
> how the command should behave. The grep unix utility is a example to
> copy. Under normal operation, grep always exits 0 unless an error
> happens, regardless of whether it found any matches. Invoking grep with
> the -q/--quiet flag causes grep to be silent, not printing anything, as
> well as exiting 0 if matches are found and 1 if nothing is found.
> 
> I am proposing django-admin makemigrations should exit with 1 (or
> anything non-zero) if no migrations to make were found, or exit 0 if
> migrations to make were found. As the command is instructed to make
> migrations, not making any is the error case.
> 
> I am unsure how this new functionality should be selected by the user
> when invoking makemigrations. The options I see are:
> 
>  1. Enable this always. This is very simple to implement and easy to
> understand. Good unixy tools use error codes extensively to signal
> errors. This may be surprising behaviour when compared to grep
> though, and breaks backwards compatibility in a minor way.
>  2. Enable this when the --dry-run flag is enabled. Now this flag can be
> used to check for migrations that need to be created both visually
> via the printed text, and composed in shell commands.
>  3. Add a new flag -e/--exit (or similar). The sole purpose of this flag
> would be to exit with 1 when no migrations were found. This could be
> combined with --dry-run to just check for migrations that need to be
> made.
>  4. Add a new flag -q/--quiet that copies the behaviour of greps
> -q/--quiet flag: silences output and exits with 1 when no migrations
> were found. This duplicates functionality though, as logging can be
> silenced using -v0 already.
> 
> My personal preference is for option 2. I was surprised when enabling
> --dry-run did not signal its result via the exit code. 3 would be the
> cleanest and most composable option, as 4 could be emulated using -ev0.
> 
> I will implement this change using 2, unless other people have opinions
> on the matter.
> 
> Regards,
> Tim
> 
> -- 
> 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/92203dcb-a775-4c17-a831-97d01ce8af3c%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.


-- 
"I was sad because I had no shoes, until I met a man who had no
feet. So I said, "Got any shoes you're not using?"  (Steven Wright)

Luke Plant || http://lukeplant.me.uk/

-- 
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