Adrian Holovaty wrote: > (I've been saving this e-mail since the last sprint. Given that we're > sprinting again this weekend, I figured it was about time to get this > conversation started.) > > Let's get a definitive list of features we want in Django 1.0, and > let's release it. > > I'll start with a proposed list, which no doubt has omissions. But > first, here's a proposal for how to handle this: > > 1. We decide on the list of features/changes. > > 1.5. Once the list is final, we do NOT add to it except in case of > an Act of God. > > 2. We set a deadline. > > 3. We work -- *primarily* on the list of features/changes, but > allowing some time for squeezing in any other small fixes that we have > time for. > > 4. Any feature that's not implemented by the deadline does NOT > make it into version 1.0. But fear not, because version 1.0 is not the > end of Django -- it's only the beginning! > > 5. Release, rejoice. > > The first order of business is deciding the features/changes. I'll > kick it off with the list I've been keeping. > > This is just my own list, of course, and I'm sure other > committers/contributors have other stuff. Please contribute! Just one > important thing to note: This list is for Big Stuff only. Do not > suggest features that would be able to be added/changed *after* the > 1.0 release in a backwards-compatible way. The goal here is to have a > simple, concrete list of major things that need to be done to the > framework -- not a list of 4,000 tiny things. > > Without further ado, here's my list: > > * newforms-admin > * queryset-refactor > * django.newforms becomes django.forms > * Model-level validation > * Change django.templatetags not to use __path__ hacking > * #3591 -- Make INSTALLED_APPS an instance, and each app an instance > * #5361 -- File storage refactoring > * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff > > What am I forgetting?
There is probably no ticket for it, but allowing a WSGI environment variable be used in place of DJANGO_SETTINGS_MODULE environment variable. The intent in doing this is to get away from dependence on what is effectively a global variable. This would perhaps allow, or at least be a step on the way to being able to effectively host multiple Django site instances within the one Python interpreter. This would be better than using distinct sub interpreters in mod_python or mod_wsgi as only have to load common modules into memory once, thus cutting down on memory bloat when hosting a lot of sites. I think a lot of people who are hosting a lot of related sites on the one system would appreciate this one. Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
