Re: Feature lists for 1.2

On Fri, Oct 23, 2009 at 11:21 PM, Jacob Kaplan-Moss wrote: > > > So any tickets that have the full gambit of patch/docs/tests should make > it > > into 1.2? > > In theory. Keep in mind, though, that us committers have limited > mental bandwidth so we can't absolutely promise

Re: Feature lists for 1.2

> So any tickets that have the full gambit of patch/docs/tests should make it > into 1.2? In theory. Keep in mind, though, that us committers have limited mental bandwidth so we can't absolutely promise to get to every single ticket. I'll do my best, of course, but at the end of the day I'm

Re: Feature lists for 1.2

On Fri, Oct 23, 2009 at 5:29 PM, Jacob Kaplan-Moss wrote: > > 2009/10/23 kmike : > > Some features from wiki proposal page don't get their way to google > > spreadsheet (ex: 2 cache-related proposals) and they are not mentioned > > in the final features

Re: The this-needs-to-be-in-django angst

On Oct 23, 1:42 am, Waldemar Kornewald wrote: > On Friday, October 23, 2009, James Bennett wrote: > > > On Thu, Oct 22, 2009 at 11:20 PM, Vinay Sajip > > wrote: > >> How about using BitBucket? Does it have the same

Re: Django 1.2 feature voting

On Fri, Oct 23, 2009 at 5:12 AM, rjc wrote: > The only reason I will migrate to 1.2 is if you include schema > migration. It is that important for us (we have a lot of production > code out). Anyway, why did we pick south instead of django-evolution ? > I'm +1 (+1 +1) for

Re: Feature lists for 1.2

2009/10/23 kmike : > Some features from wiki proposal page don't get their way to google > spreadsheet (ex: 2 cache-related proposals) and they are not mentioned > in the final features page neither in a list of accepted features nor > in a list of rejected features.

Re: Feature lists for 1.2

Some features from wiki proposal page don't get their way to google spreadsheet (ex: 2 cache-related proposals) and they are not mentioned in the final features page neither in a list of accepted features nor in a list of rejected features. I understand that there are some valid reasons for that

Re: non-relational DB

I just want to remind contributers to fill in the cell "Assigned to" and "Status" in the task spreadsheet while working on a specific task in order to prefend problems. Here is the link: https://spreadsheets.google.com/ccc?key=0AnLqunL-SCJJdE1fM0NzY1JQTXJuZGdEa0huODVfRHc=en Bye, Thomas Wanschik

Feature lists for 1.2

Hi folks -- Based on the votes and comments I've received for Django 1.2 I've prepared a breakdown of features into high, medium, and low priority: http://code.djangoproject.com/wiki/Version1.2Features. I've noted associated committers and, where I know 'em, lieutenants. Please make corrections

Re: 1.2 Feature Suggestion

On Fri, 2009-10-23 at 16:30 +0200, Jonas Obrist wrote: > Oh... Well than consider this a 1.X suggestion. I've tried Rosetta > however it just doesn't seem to work Also I don't really like to use > 3rd Party apps for what I'd consider core functionality. I mean django > boasts with having

Re: 1.2 Feature Suggestion

Oh... Well than consider this a 1.X suggestion. I've tried Rosetta however it just doesn't seem to work Also I don't really like to use 3rd Party apps for what I'd consider core functionality. I mean django boasts with having excellent i18n capabilities, but when it comes to actually

Re: 1.2 Feature Suggestion

On Fri, Oct 23, 2009 at 10:21 AM, Jonas Obrist wrote: > > How about making  i18n strings translatable from the django admin site? > I like how the whole i18n thingy is built from a template perspective, > however getting the stuff actually translated (all those

1.2 Feature Suggestion

How about making i18n strings translatable from the django admin site? I like how the whole i18n thingy is built from a template perspective, however getting the stuff actually translated (all those django-admin.py commands ...) is a pain and confusing. So why not integrate this into the

Re: Django 1.2 feature voting

The only reason I will migrate to 1.2 is if you include schema migration. It is that important for us (we have a lot of production code out). Anyway, why did we pick south instead of django-evolution ? I'm +1 (+1 +1) for any db schema migration. I'm +1 for admin ui branch integration. Django

Re: default Model.all()?

On Friday 23 October 2009 10:37:11 Philippe Raoult wrote: > I have the following shorcut in my code: > > class IterableManager(models.Manager): > use_for_related_fields = True > > def __iter__(self): > return self.all().__iter__() > > class CustomModel(models.Model):

Re: default Model.all()?

I have the following shorcut in my code: class IterableManager(models.Manager): use_for_related_fields = True def __iter__(self): return self.all().__iter__() class CustomModel(models.Model): objects = IterableManager() I'm honestly not

Attribute docstrings

\\//, I'm using sphinx to document my Django apps and have an issue with attribute docstrings. Right now Django does not make CharFields or BooleanFields top level attributes like FK's or m2m's. This however makes that Doc processors cannot see the docstrings of those types. Is there a way to