Re: Feedback on ticket #12399

2010-01-26 Thread Gert Van Gool 
The second patch [1] fixes the memcached backend.

[1]
http://code.djangoproject.com/attachment/ticket/12399/memcached-timeout-fixes.diff
-- Gert

Mobile: +32 498725202
Web: http://gert.selentic.net


On Wed, Jan 27, 2010 at 08:28, Kristian Klette  wrote:

> > It's a nasty bug which leads to a 100% cache misses situation on
> > memcached when using long keys timeouts.
>
> Wouldn't it be better to fix this in the memcache backend itself? It does
> cause a backward compatibility problem for users that do takes this
> memcached
> behaviour into account in their code though.
>
> Either way, this memcached behaviour should be mentioned in the cache
> documentation.
>
> - Kristian
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Feedback on ticket #12399

2010-01-26 Thread Kristian Klette 
> It's a nasty bug which leads to a 100% cache misses situation on
> memcached when using long keys timeouts.

Wouldn't it be better to fix this in the memcache backend itself? It does
cause a backward compatibility problem for users that do takes this memcached
behaviour into account in their code though.

Either way, this memcached behaviour should be mentioned in the cache
documentation.

- Kristian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Deleting related objects in the admin: patch for #6191

2010-01-26 Thread Carl Meyer 
On Jan 26, 7:24 pm, Russell Keith-Magee 
wrote:
> I'll put it on my list. It will probably still be a 'post 1.2-beta'
> activity, but I'll try to look at it at the start of the bugfixing
> phase.

Great, thanks. Looking forward your feedback.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Pony request: refetch method to models

2010-01-26 Thread Russell Keith-Magee 
On Wed, Jan 27, 2010 at 12:59 AM, Jukka  wrote:
> Hi all,
>
> I'd like to propose adding a method to Model that can be used to fetch
> a "fresh" version of a model object from the database.

This isn't a completely unreasonble idea, but it is an unreasonable
time to suggest it :-)

We are days away from our feature freeze for 1.2. At this point, any
new ideas will need to wait until 1.3.

I'm fairly certain this idea has been proposed before, so there's
probably a ticket for it, too. If there isn't, open a new ticket so we
don't forget the idea.

If you want to propose this for 1.3, keep an eye on the release
schedule; once 1.2 is released, we'll start discussing the features we
want in 1.3.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Deleting related objects in the admin: patch for #6191

2010-01-26 Thread Russell Keith-Magee 
On Wed, Jan 27, 2010 at 2:00 AM, Carl Meyer  wrote:
> Hey all,
>
> During the Chicago sprint a few weeks ago I put together a patch for
> #6191: the admin's "the following related objects will be deleted"
> list in some cases omits items that actually are deleted (oops!). The
> admin has its own routine for collecting related objects for
> notification, separate from the ORM code that collects the objects for
> deletion. This situation seemed ripe for further discrepancies down
> the road, so rather than just fixing the immediate bug in the admin
> routine I opted to make the admin notification reuse the ORM's
> collect_sub_objects() method, so the same logic that is used to
> actually delete the objects is used for the notification.
>
> I'd love to get this fix in for 1.2 if possible, since it involves
> silent loss of data. It's a bug fix, so can go in post-beta; but it's
> also a relatively large patch, so it seems like getting more eyes on
> it sooner rather than later would be good. Patch works well for me, I
> added a number of new tests and tests are passing (well, two unrelated
> admin_views tests currently fail for me with or without the patch).
> Anyone up for taking a look?

I'll put it on my list. It will probably still be a 'post 1.2-beta'
activity, but I'll try to look at it at the start of the bugfixing
phase.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Feedback on ticket #12399

2010-01-26 Thread Russell Keith-Magee 
On Wed, Jan 27, 2010 at 12:30 AM, Giuseppe Ciotta  wrote:
> http://code.djangoproject.com/ticket/12399
>
> It's a nasty bug which leads to a 100% cache misses situation on
> memcached when using long keys timeouts.
>
> Do you think we can have this included in 1.2? Should i mark it with
> Version:1.2 or something? The patch itself is trivial.

Marking the ticket as "Milestone 1.2" will put it on the list of bugs
that will be considered for 1.2.

Looking at the patch, the one thing that is missing is tests. Without
tests, a patch won't get anywhere near trunk, no matter how trivial.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Feedback requested: One last time with multi-db

2010-01-26 Thread Brett Hoerner 
On Jan 23, 7:05 am, Russell Keith-Magee 
wrote:
> A full explanation, including an example is in the documentation
> portion of the patch, attached to ticket #12542.
>
> Comments?

This fixed our only (known) blocking problem towards 1.2, thanks so
much.

Brett

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Pony request: refetch method to models

2010-01-26 Thread Chris 
On Jan 26, 11:59 am, Jukka  wrote:
> Hi all,
>
> I'd like to propose adding a method to Model that can be used to fetch
> a "fresh" version of a model object from the database. This is
> something that I personally would often find useful. Usually this
> happens when I'm testing some view code using the test client, and the
> view is supposed to save some model changes into database. For
> example:
>
> client.post('some_url', {'id': obj.id, 'description': 'new'})
> fresh_obj = ObjClass.objects.get(pk=obj.pk)
> self.assertEqual('new', fresh_obj.description)
>
> Now, I think that way of refreshing a model object is inelegant. What
> I propose is a method that would be functionally identical to how a
> fresh object is fetched above:
>
> fresh_obj = obj.refetch()
>
> This is a convenience method, but based on my own experience it would
> be... well, convenient. I'd like to hear whether you think the
> convenience would be worth extending the api. If you think it's worth
> it, I'd be happy to write a patch.
>
> --Jukka

Why not just make a custom model method?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Deleting related objects in the admin: patch for #6191

2010-01-26 Thread Carl Meyer 
Hey all,

During the Chicago sprint a few weeks ago I put together a patch for
#6191: the admin's "the following related objects will be deleted"
list in some cases omits items that actually are deleted (oops!). The
admin has its own routine for collecting related objects for
notification, separate from the ORM code that collects the objects for
deletion. This situation seemed ripe for further discrepancies down
the road, so rather than just fixing the immediate bug in the admin
routine I opted to make the admin notification reuse the ORM's
collect_sub_objects() method, so the same logic that is used to
actually delete the objects is used for the notification.

I'd love to get this fix in for 1.2 if possible, since it involves
silent loss of data. It's a bug fix, so can go in post-beta; but it's
also a relatively large patch, so it seems like getting more eyes on
it sooner rather than later would be good. Patch works well for me, I
added a number of new tests and tests are passing (well, two unrelated
admin_views tests currently fail for me with or without the patch).
Anyone up for taking a look?

Thanks,

Carl

[1] http://code.djangoproject.com/ticket/6191

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: errors with URLs in them

2010-01-26 Thread Andy McKay 

On 2010-01-21, at 3:53 PM, Russell Keith-Magee wrote:

> On Fri, Jan 22, 2010 at 1:35 AM, Andy McKay  wrote:
>> 
>> This is of course won't be possible for all errors or all parts of Django, 
>> but would work for some of the more common errors that crop up regularly. 
>> Would this be a course worth pursuing?
> 
> I'd say yes - with some caveats.
> 
> Firstly, we need to be careful about casting too wide a net in
> catching errors. We don't want to accidentally catch errors and give a
> solution that is wrong. We also don't want to hide useful errors under
> a 'helpful' blanket (e.g., the way that Django sometimes masks import
> errors). If we're going to introduce specific error messages, we need
> to make sure they actually refer to a specific problem.

Absolutely, this should be used sparingly. It just can be a bit frustrating 
because some of the start up or import errors can be a bit silent or cryptic.

> I'm always hesitant to blame the user for problems like this. If the
> user isn't following instructions, maybe the instructions aren't clear
> enough. Maybe the error message in question is just too pithy --
> perhaps if they redirected to a single page in the docs that gave a
> verbose explanation of the problem (including examples and workarounds
> where appropriate), we might be able to avoid a few of these
> questions.
> However, in the words of Cool Hand Luke: "some folks, you just can't reach". 
> :-)

I think it might help, you are right and we can't save everyone. But I think if 
we can document the error properly and in some detail somewhere, we'll at least 
feel good that we've done everything we can.

> So - if you can produce a patch that demonstrates 5-10 examples of
> patterns that would benefit from an elaborate error message, I
> certainly think that patch could find it's way into trunk.


Rightio, we'll give it a try a for a few and see how it lookis.

Thanks for the
--
  Andy McKay, @clearwind
  http://clearwind.ca/djangoski

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Pony request: refetch method to models

2010-01-26 Thread Jukka 
Hi all,

I'd like to propose adding a method to Model that can be used to fetch
a "fresh" version of a model object from the database. This is
something that I personally would often find useful. Usually this
happens when I'm testing some view code using the test client, and the
view is supposed to save some model changes into database. For
example:

client.post('some_url', {'id': obj.id, 'description': 'new'})
fresh_obj = ObjClass.objects.get(pk=obj.pk)
self.assertEqual('new', fresh_obj.description)

Now, I think that way of refreshing a model object is inelegant. What
I propose is a method that would be functionally identical to how a
fresh object is fetched above:

fresh_obj = obj.refetch()

This is a convenience method, but based on my own experience it would
be... well, convenient. I'd like to hear whether you think the
convenience would be worth extending the api. If you think it's worth
it, I'd be happy to write a patch.

--Jukka

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Feedback on ticket #12399

2010-01-26 Thread Giuseppe Ciotta 
http://code.djangoproject.com/ticket/12399

It's a nasty bug which leads to a 100% cache misses situation on
memcached when using long keys timeouts.

Do you think we can have this included in 1.2? Should i mark it with
Version:1.2 or something? The patch itself is trivial.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: AnonymousUser has_perm/has_module_perms function check authentication backends

2010-01-26 Thread Florian Apolloner 
On Jan 26, 3:19 pm, Harro  wrote:
> - If the default backend always returns false for anonymous users then
> pluggable apps have to either expect some row level permission system
> is installed and used or don't check permissions for things that an
> anonymous user can access.
Why do they have to expect a row level permission system to be
installed? The ModelBackend would always return False for anonymous,
so everything would stay as it is…

> I think the best solution is to add anonymous user permissions as
> proposed by me a bit up, but only actually check them if a settings
> flag is set to True (with a default on False). If it's not set it will
> simply return False for anonymous users, otherwise it will check the
> permissions.
I am -1 on that, using `supports_anonymous_users` is way better and
allows a cleaner upgrade path (as every backend will have to support
anonymous users sooner or later)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: AnonymousUser has_perm/has_module_perms function check authentication backends

2010-01-26 Thread Luke Plant 
On Tuesday 26 January 2010 12:12:23 Jari Pennanen wrote:
> I read from "1.2 beta" thread that this might make it to the 1.2
>  beta of Django, any status on that? Is someone trying to commit
>  the patches?

Florian Apolloner pointed out that it had backwards incompatibility 
issues.  I'm hoping to look at it tonight and see what I can do, 
probably along the lines of a 'supports_anonymous_users' attribute, 
like the 'supports_object_permissions' attribute.  If anyone else can 
do a patch and let me know before 21:00 GMT, that would be great.

Luke

-- 
"The first ten million years were the worst. And the second ten 
million, they were the worst too. The third ten million, I didn't 
enjoy at all. After that I went into a bit of a decline." (Marvin 
the paranoid android)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: AnonymousUser has_perm/has_module_perms function check authentication backends

2010-01-26 Thread Harro 
I think so far we agree that we need to add something for anonymous
users, because the added enhancement currently doesn't add enough to
integrate row level permissions as they should be.
The problems are:

- Anonymous users should check the authentication backend for
permissions, so it is possible to implement anonymous user permissions
- If the default backend always returns false for anonymous users then
pluggable apps have to either expect some row level permission system
is installed and used or don't check permissions for things that an
anonymous user can access.


I think the best solution is to add anonymous user permissions as
proposed by me a bit up, but only actually check them if a settings
flag is set to True (with a default on False). If it's not set it will
simply return False for anonymous users, otherwise it will check the
permissions.

That way pluggable apps decide for themselves if they want to check
permissions for all users and if they do throw an error if the flag is
not set. Or if they simply do it the old way by doing a login_required
for the views that need logged in users.



On Jan 26, 1:12 pm, Jari Pennanen  wrote:
> I read from "1.2 beta" thread that this might make it to the 1.2 beta
> of Django, any status on that? Is someone trying to commit the patches?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Translation patch and the I18N mailinglist

2010-01-26 Thread TiNo 
On Tue, Jan 26, 2010 at 11:04, Jannis Leidel  wrote:

> Am 25.01.2010 um 23:06 schrieb TiNo :
>
>
>  Hi,
>>
>> I posted a message [1] to the Django I18N list on the 28th of December.
>> Apparently, it is also the last message to that list. Is the I18N list dead?
>>
>
> No, the mailing list isn't dead :)
>
> Jannis


Ok, then I'll assume no dutch people are reading it, or nobody has an
objection to the translation I suggested :)

Tino

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: 1.2 beta?

2010-01-26 Thread Luke Plant 
On Tuesday 26 January 2010 11:30:45 Florian Apolloner wrote:
> Hi,
> 
> I am far away from beeing a commiter, but would like to get some
> thoughts about the AnonymousUser permission checks written down
>  (I'll keep it short to not hijack this thread): By the time I
>  moved permission checks to the backends I didn't thought much
>  about anonymous users (I guess that was bad, but by that time I
>  never needed it). The current situation is as follows: If we pass
>  the AnonymousUser into the backend we will berak any code that
>  relied on the User object to be in the database [disclaimer: as
>  far as I can tell, we always said that the programmer should check
>  if the User is authenticated or not, but as we never passed
>  AnonymousUser into the backends I doubt someone checks that.
>  Though I guess most people used the backends to check against ldap
>  etc, so this would be a non issue…]. If you are okay with that, I
>  am +1 on whatever needs to be done to get this feature in.

That's a good catch.  Previously I was thinking that the change only 
affected the "per object" code, which was added since 1.1.

The changed required to handle AnonymousUser is pretty simple, as 
demonstrated by the patch on the provided auth backend.  However, it 
could easily catch people out.

One possible migration strategy is to add a 'supports_anonymous_user' 
attribute, similar to 'supports_object_permissions'.

Luke


-- 
"The first ten million years were the worst. And the second ten 
million, they were the worst too. The third ten million, I didn't 
enjoy at all. After that I went into a bit of a decline." (Marvin 
the paranoid android)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: 1.2 beta?

2010-01-26 Thread Jannis Leidel 
Am 26.01.2010 um 12:30 schrieb Florian Apolloner:

> I am far away from beeing a commiter, but would like to get some
> thoughts about the AnonymousUser permission checks written down (I'll
> keep it short to not hijack this thread): By the time I moved
> permission checks to the backends I didn't thought much about
> anonymous users (I guess that was bad, but by that time I never needed
> it). The current situation is as follows: If we pass the AnonymousUser
> into the backend we will berak any code that relied on the User object
> to be in the database [disclaimer: as far as I can tell, we always
> said that the programmer should check if the User is authenticated or
> not, but as we never passed AnonymousUser into the backends I doubt
> someone checks that. Though I guess most people used the backends to
> check against ldap etc, so this would be a non issue…]. If you are
> okay with that, I am +1 on whatever needs to be done to get this
> feature in.

As mentioned in the other thread, I'm sceptical about adding more meaning to 
the AnonymousUser (making it a workflow item instead of a placeholder for "this 
request was made by a non-authorized user"). -0

The major issue here is backwards compatibility though. I'd be glad to know how 
we'd handle this.

> Aside from that I would like to know what the status on admin-ui is,
> as Janis worked on that lately. That said I don't see any real reason
> why we would need to postpone the beta.

This is indeed on my today's todo list, I worked on it during the sprint last 
weekend.

Jannis

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: AnonymousUser has_perm/has_module_perms function check authentication backends

2010-01-26 Thread Jari Pennanen 
I read from "1.2 beta" thread that this might make it to the 1.2 beta
of Django, any status on that? Is someone trying to commit the patches?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: 1.2 beta?

2010-01-26 Thread Florian Apolloner 
Hi,

I am far away from beeing a commiter, but would like to get some
thoughts about the AnonymousUser permission checks written down (I'll
keep it short to not hijack this thread): By the time I moved
permission checks to the backends I didn't thought much about
anonymous users (I guess that was bad, but by that time I never needed
it). The current situation is as follows: If we pass the AnonymousUser
into the backend we will berak any code that relied on the User object
to be in the database [disclaimer: as far as I can tell, we always
said that the programmer should check if the User is authenticated or
not, but as we never passed AnonymousUser into the backends I doubt
someone checks that. Though I guess most people used the backends to
check against ldap etc, so this would be a non issue…]. If you are
okay with that, I am +1 on whatever needs to be done to get this
feature in.

Aside from that I would like to know what the status on admin-ui is,
as Janis worked on that lately. That said I don't see any real reason
why we would need to postpone the beta.

Cheers,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Translation patch and the I18N mailinglist

2010-01-26 Thread Jannis Leidel 

Am 25.01.2010 um 23:06 schrieb TiNo :


Hi,

I posted a message [1] to the Django I18N list on the 28th of  
December. Apparently, it is also the last message to that list. Is  
the I18N list dead?


No, the mailing list isn't dead :)

Jannis





--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Translation patch and the I18N mailinglist

2010-01-26 Thread TiNo 
On Tue, Jan 26, 2010 at 01:55, Russell Keith-Magee
wrote:

> On Tue, Jan 26, 2010 at 6:06 AM, TiNo  wrote:
> > Hi,
> > The reason I posted there was to see if anybody had any objections to the
> > one-liner patch [2] I suggested for a dutch translation that is wrong at
> the
> > moment. It would be really nice to see this checked in for 1.2, as it has
> > been looking quite confusing in the admin for quite a while now.
>
> Translations are traditionally the last thing that gets committed.As
> long as the ticket is marked for the translations component, it's
> almost guaranteed to get committed before 1.2 final.
>

Ok, thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.