Re: Ticket 13023: Admin inlines, max_num, and extra

[Gabriel Hurley]

Thanks for the IRC log, Ivan. That offers some perspective.

Ideally a complete solution would have the following characteristics:

1. Makes behavior consistent with or without Javascript enabled. I
personally would argue against any solution that caused extra and
max_num to have different effects with and without JS.

2. Preserves existing behaviors from 1.1 for both extra and max_num.
If those behaviors become "features" instead of "unintended side-
effects" that's cool, but IMHO removing those behaviors doesn't
benefit Django overall. Even if it means codifying the "feature" into
something more like readonly that is no longer tied to max_num and
extra.

3. Clarifies the meaning of max_num = 0. Currently max_num being 0 has
a very odd behavior, and while it would be somewhat silly to create an
Admin that had inlines but said the maximum number was 0, it seems
equally strange that if I deliberately set max_num to 0 that it is, in
fact, ignored.

I guess in a sense, I really see three separate but related issues
here. Anyhow, that's where I'm at with it. I'd love to hear from some
of the core devs, since they've already given it some thought, and
will make the ultimate decision about any changes that take place.

   - Gabriel

On Mar 16, 7:56 pm, Iván Raskovsky  wrote:
> Hi Gabriel, here's a follow up after I asked in django-dev if I should file
> the ticket:http://botland.oebfare.com/logger/django-dev/2010/3/4/1/
> Unfortunately I can't find my original conversation.
>
> One thing that might be important to take into consideration is that without
> the patch users without JS enabled can't add any new inlines, so if the
> patch is rejected, we should be fixing that instead.
>
> For what is worth, IMHO documented or not this was a behavior I'm sure I
> wasn't the only one taking advantage of, and would very much like to see in
> 1.2 so I can update my 1.1 projects and take advantage of all the new
> features without breaking the actual functionality.
>
> I'd like to take the opportunity and thank you for this patch and another
> one in a ticket I filed. Thanks,
>     Iván
>
>
>
> On Tue, Mar 16, 2010 at 8:10 PM, Gabriel Hurley  wrote:
> > I couldn't help notice that #13023 was mentioned in Russ' latest 1.2
> > status update as a ticket that "will require some significant design
> > work". Since I've accepted that ticket I'd love to get some feedback
> > from folks.
>
> > The ticket:http://code.djangoproject.com/ticket/13023
>
> > The ticket was opened because the new javascript "Add Another"
> > functionality for admin inlines caused a useful (though possibly
> > unintended) feature to be removed: when setting extra to 0 you could
> > display existing inlines without allowing any new ones to be created.
> > The new javascript made this impossible because the "Add Another"
> > button was controlled by max_num, and ignored a value of 0.
>
> > When I tracked back through the code, I realized there was a more
> > fundamental problem: the javascript ignored a value of 0 because
> > max_num has a default value of 0, and all the code using it had taken
> > to equating max_num = 0 with being "off". So you can't actually have a
> > maximum of 0. It's not possible.
>
> > My patch for the ticket restored the desired behavior for admin
> > inlines, but I'll admit it was a bit of a hack and didn't address the
> > larger problem. I wasn't sure the larger problem was appropriate to
> > fix in the 1.2 timeframe.
>
> > So what is the appropriate course here? Should the default value and
> > behavior of max_num be changed? Does the entire feature need to be re-
> > evaluated? Are there other issues involved that I'm missing entirely?
>
> > I'm happy to work on the ticket (and have a reasonable grasp on that
> > area of the codebase), but I need some direction.
>
> > Thanks so much!
>
> >    - Gabriel
>
> > --
> > 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 > i...@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: Ticket 13023: Admin inlines, max_num, and extra

[Iván Raskovsky]

Hi Gabriel, here's a follow up after I asked in django-dev if I should file
the ticket: http://botland.oebfare.com/logger/django-dev/2010/3/4/1/
Unfortunately I can't find my original conversation.

One thing that might be important to take into consideration is that without
the patch users without JS enabled can't add any new inlines, so if the
patch is rejected, we should be fixing that instead.

For what is worth, IMHO documented or not this was a behavior I'm sure I
wasn't the only one taking advantage of, and would very much like to see in
1.2 so I can update my 1.1 projects and take advantage of all the new
features without breaking the actual functionality.

I'd like to take the opportunity and thank you for this patch and another
one in a ticket I filed. Thanks,
Iván


On Tue, Mar 16, 2010 at 8:10 PM, Gabriel Hurley  wrote:

> I couldn't help notice that #13023 was mentioned in Russ' latest 1.2
> status update as a ticket that "will require some significant design
> work". Since I've accepted that ticket I'd love to get some feedback
> from folks.
>
> The ticket: http://code.djangoproject.com/ticket/13023
>
> The ticket was opened because the new javascript "Add Another"
> functionality for admin inlines caused a useful (though possibly
> unintended) feature to be removed: when setting extra to 0 you could
> display existing inlines without allowing any new ones to be created.
> The new javascript made this impossible because the "Add Another"
> button was controlled by max_num, and ignored a value of 0.
>
> When I tracked back through the code, I realized there was a more
> fundamental problem: the javascript ignored a value of 0 because
> max_num has a default value of 0, and all the code using it had taken
> to equating max_num = 0 with being "off". So you can't actually have a
> maximum of 0. It's not possible.
>
> My patch for the ticket restored the desired behavior for admin
> inlines, but I'll admit it was a bit of a hack and didn't address the
> larger problem. I wasn't sure the larger problem was appropriate to
> fix in the 1.2 timeframe.
>
> So what is the appropriate course here? Should the default value and
> behavior of max_num be changed? Does the entire feature need to be re-
> evaluated? Are there other issues involved that I'm missing entirely?
>
> I'm happy to work on the ticket (and have a reasonable grasp on that
> area of the codebase), but I need some direction.
>
> Thanks so much!
>
>- Gabriel
>
> --
> 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: Deprecating cmemcache, adding pylibmc

[mrts]

On Mar 1, 5:27 pm, Jacob Kaplan-Moss  wrote:
> Also, a step 2.5, if you'd like, would be to write a tiny app on pypi
> that enabled the use of pylibmc via an external cache backend. We
> could point to it in the deprecation notes when we explain why
> cmemcache is being deprecated.

See http://gist.github.com/334682

Best,
MS

-- 
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: logialogin_required does not check User.is_active

[mattd]

interesting. i'm using the django-provided login form from 1.1,
waiting for 1.2 to be released before using it.

here's an example of my point: you run an internal tool for staff to
discuss the topics of the day. a few staff are let go or otherwise
deemed ineligible, and their access is revoked. so, you deactivate
their accounts in the lovely django admin, but then find that they are
still using the site. now, deactivating them doesn't log them out, and
that's to be expected since contrib.sessions is wisely decoupled from
contrib.auth. but, you thought you'd protected your views with
"login_required", but it turns out "login_required" only makes sure
that the user is currently logged in, riding on the assumption that
their status would not change in the duration of their session.

to me, it seems like an oversight. definitely interested in others'
opinions.



On Mar 16, 5:25 pm, Gabriel Hurley  wrote:
> I linked to the 1.1 docs there, but the 1.2 docs add:
>
> "However, the AuthenticationForm used by the login() view does perform
> this check, as do the permission-checking methods such as has_perm()
> and the authentication in the Django admin."
>
> So in this instance, if using the built-in django login view is your
> only method of logging in to your site you would be safe. I'll admit
> the whole business of not checking is_active seems a little odd to me,
> but I also haven't looked to see what discussion there was around the
> original decision. I'd hope it would make more sense if I did look
> back in the archives.
>
> I'm no expert on this one. Just thought I'd point out the fact that
> the docs do discuss the subject of that bug ticket.
>
>    - Gabriel
>
> On Mar 16, 3:12 pm, mattd  wrote:
>
>
>
> > if it's a design decision, it's a silly one imo. why should i have to
> > work around django's ever-so-convenient "login_required" decorator to
> > prevent a deactivated user from viewing a page they're no longer
> > allowed to view? a deactivated user *shouldn't even be allowed to be
> > be logged in*, but there's no way (that i know of) the purge the
> > session data for a given user on deactivation, and i can't just email
> > them to politely ask them to log out.
>
> > On Mar 16, 4:48 pm, Gabriel Hurley  wrote:
>
> > > The docs have this to say about is_active:
>
> > > "This doesn’t control whether or not the user can log in. Nothing in
> > > the authentication path checks the is_active flag, so if you want to
> > > reject a login based on is_active being False, it is up to you to
> > > check that in your own login view. However, permission checking using
> > > the methods like has_perm() does check this flag and will always
> > > return False for inactive users."
>
> > >http://docs.djangoproject.com/en/1.1/topics/auth/#django.contrib.auth...
>
> > > So, if we're to believe the docs, this isn't a bug but a design
> > > decision.
>
> > > All the best,
>
> > >    - Gabriel
>
> > > On Mar 16, 1:53 pm, Sean Brant  wrote:
>
> > > > A co-worker of mine noticed this bug 
> > > > todayhttp://code.djangoproject.com/ticket/13125.
> > > > Should it be marked for 1.2 or punt it until after the release
> > > > candidate? It looks to be a bug so it could probably go in at anytime.
> > > > Let me know your thoughts.

-- 
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: logialogin_required does not check User.is_active

[Gabriel Hurley]

I linked to the 1.1 docs there, but the 1.2 docs add:

"However, the AuthenticationForm used by the login() view does perform
this check, as do the permission-checking methods such as has_perm()
and the authentication in the Django admin."

So in this instance, if using the built-in django login view is your
only method of logging in to your site you would be safe. I'll admit
the whole business of not checking is_active seems a little odd to me,
but I also haven't looked to see what discussion there was around the
original decision. I'd hope it would make more sense if I did look
back in the archives.

I'm no expert on this one. Just thought I'd point out the fact that
the docs do discuss the subject of that bug ticket.

   - Gabriel

On Mar 16, 3:12 pm, mattd  wrote:
> if it's a design decision, it's a silly one imo. why should i have to
> work around django's ever-so-convenient "login_required" decorator to
> prevent a deactivated user from viewing a page they're no longer
> allowed to view? a deactivated user *shouldn't even be allowed to be
> be logged in*, but there's no way (that i know of) the purge the
> session data for a given user on deactivation, and i can't just email
> them to politely ask them to log out.
>
> On Mar 16, 4:48 pm, Gabriel Hurley  wrote:
>
>
>
> > The docs have this to say about is_active:
>
> > "This doesn’t control whether or not the user can log in. Nothing in
> > the authentication path checks the is_active flag, so if you want to
> > reject a login based on is_active being False, it is up to you to
> > check that in your own login view. However, permission checking using
> > the methods like has_perm() does check this flag and will always
> > return False for inactive users."
>
> >http://docs.djangoproject.com/en/1.1/topics/auth/#django.contrib.auth...
>
> > So, if we're to believe the docs, this isn't a bug but a design
> > decision.
>
> > All the best,
>
> >    - Gabriel
>
> > On Mar 16, 1:53 pm, Sean Brant  wrote:
>
> > > A co-worker of mine noticed this bug 
> > > todayhttp://code.djangoproject.com/ticket/13125.
> > > Should it be marked for 1.2 or punt it until after the release
> > > candidate? It looks to be a bug so it could probably go in at anytime.
> > > Let me know your thoughts.

-- 
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: logialogin_required does not check User.is_active

[mattd]

if it's a design decision, it's a silly one imo. why should i have to
work around django's ever-so-convenient "login_required" decorator to
prevent a deactivated user from viewing a page they're no longer
allowed to view? a deactivated user *shouldn't even be allowed to be
be logged in*, but there's no way (that i know of) the purge the
session data for a given user on deactivation, and i can't just email
them to politely ask them to log out.


On Mar 16, 4:48 pm, Gabriel Hurley  wrote:
> The docs have this to say about is_active:
>
> "This doesn’t control whether or not the user can log in. Nothing in
> the authentication path checks the is_active flag, so if you want to
> reject a login based on is_active being False, it is up to you to
> check that in your own login view. However, permission checking using
> the methods like has_perm() does check this flag and will always
> return False for inactive users."
>
> http://docs.djangoproject.com/en/1.1/topics/auth/#django.contrib.auth...
>
> So, if we're to believe the docs, this isn't a bug but a design
> decision.
>
> All the best,
>
>    - Gabriel
>
> On Mar 16, 1:53 pm, Sean Brant  wrote:
>
>
>
> > A co-worker of mine noticed this bug 
> > todayhttp://code.djangoproject.com/ticket/13125.
> > Should it be marked for 1.2 or punt it until after the release
> > candidate? It looks to be a bug so it could probably go in at anytime.
> > Let me know your thoughts.

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

Ticket 13023: Admin inlines, max_num, and extra

[Gabriel Hurley]

I couldn't help notice that #13023 was mentioned in Russ' latest 1.2
status update as a ticket that "will require some significant design
work". Since I've accepted that ticket I'd love to get some feedback
from folks.

The ticket: http://code.djangoproject.com/ticket/13023

The ticket was opened because the new javascript "Add Another"
functionality for admin inlines caused a useful (though possibly
unintended) feature to be removed: when setting extra to 0 you could
display existing inlines without allowing any new ones to be created.
The new javascript made this impossible because the "Add Another"
button was controlled by max_num, and ignored a value of 0.

When I tracked back through the code, I realized there was a more
fundamental problem: the javascript ignored a value of 0 because
max_num has a default value of 0, and all the code using it had taken
to equating max_num = 0 with being "off". So you can't actually have a
maximum of 0. It's not possible.

My patch for the ticket restored the desired behavior for admin
inlines, but I'll admit it was a bit of a hack and didn't address the
larger problem. I wasn't sure the larger problem was appropriate to
fix in the 1.2 timeframe.

So what is the appropriate course here? Should the default value and
behavior of max_num be changed? Does the entire feature need to be re-
evaluated? Are there other issues involved that I'm missing entirely?

I'm happy to work on the ticket (and have a reasonable grasp on that
area of the codebase), but I need some direction.

Thanks so much!

- Gabriel

-- 
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: logialogin_required does not check User.is_active

[Gabriel Hurley]

The docs have this to say about is_active:

"This doesn’t control whether or not the user can log in. Nothing in
the authentication path checks the is_active flag, so if you want to
reject a login based on is_active being False, it is up to you to
check that in your own login view. However, permission checking using
the methods like has_perm() does check this flag and will always
return False for inactive users."

http://docs.djangoproject.com/en/1.1/topics/auth/#django.contrib.auth.models.User.is_active

So, if we're to believe the docs, this isn't a bug but a design
decision.

All the best,

   - Gabriel

On Mar 16, 1:53 pm, Sean Brant  wrote:
> A co-worker of mine noticed this bug 
> todayhttp://code.djangoproject.com/ticket/13125.
> Should it be marked for 1.2 or punt it until after the release
> candidate? It looks to be a bug so it could probably go in at anytime.
> Let me know your thoughts.

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

logialogin_required does not check User.is_active

[Sean Brant]

A co-worker of mine noticed this bug today 
http://code.djangoproject.com/ticket/13125.
Should it be marked for 1.2 or punt it until after the release
candidate? It looks to be a bug so it could probably go in at anytime.
Let me know your thoughts.

-- 
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: Call for sprinters for 1.2

[Tobias McNulty]

Hi all,

We're doing another Django sprint THIS WEEKEND at Carrboro Creative
Coworking in the NC Triangle, for anyone in the area:

http://code.djangoproject.com/wiki/Sprint201003TriangleNC

Again the sprint is this weekend, March 20 & 21, from 9am to 5pm both days.
 Caktus will be sponsoring again with lunch both days - but more sponsors
for drinks, snacks, etc. would be great.  Just add your name & what you want
to bring to the list on the wiki page.

Everyone's welcome - if you haven't worked on Django before, a sprint is the
best place to start out. Hope to see you there!

Cheers,
Tobias

On Tue, Mar 16, 2010 at 11:08 AM, James Bennett wrote:

> Russ is about to put up a post on the Django weblog with the current
> state of 1.2. There's been quite a bit of progress since the last
> update, but there are still around 60 tickets which will need in-depth
> attention before we hit the point of releasing 1.2; the remainder of
> the tickets on the milestone are mostly trivial (documentation
> updates, translation fixes and other minor issues).
>
> To help get these tickets resolved (and 1.2 out the door), we'd like
> to organize a 1.2 sprint either this weekend (March 20/21) or the next
> (March 27/28), and put out a call for anyone who's willing and able to
> join in. The focus will be entirely on the 1.2 milestone tickets, with
> the goal of resolving as many as possible and getting to the 1.2
> release candidate. So if you're interested and would like to help out,
> please head over to the wiki page for the sprint:
>
> http://code.djangoproject.com/wiki/1.2ReleaseCandidateSprint
>
> and add your name and when you'll be able to sprint.
>
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of
> correct."
>
> --
> 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.
>
>


-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com

-- 
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: Model validation outside of ModelForms.

[Harro]

Just my brainfart when looking at this: Can't you simply add a pre
save signal to call the full clean method?

Dunno if that will work or not, just the first thing I would try.


On Mar 16, 5:12 pm, James Bennett  wrote:
> On Tue, Mar 16, 2010 at 10:36 AM, orokusaki  wrote:
> > It doesn't seem that the core team is interested in working on Model
> > validation at the moment:http://code.djangoproject.com/ticket/13121
> > (my failed ticket)
>
> Stop right there and actually go back and *read* all the feedback
> you've gotten, because right now you're just flat-out lying. Russell
> has, on multiple occasions, asked you, begged you, and pleaded with
> you to get proper discussion going on the things you've proposed.
> You've refused and instead adopted a method of opening duplicate
> tickets and screwing around with the metadata on existing ones,
> apparently out of a desire to annoy as many people as possible rather
> than get anything useful done.
>
> If you'll actually pay attention to what others say and actually put
> in the time to learn how the Django development process works, you may
> be a lot happier with the results. If instead you just continue what
> you've been doing, well, I for one will be happy to direct you to some
> other framework that's willing to put up with such antics.
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of correct."

-- 
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: Model validation outside of ModelForms.

[James Bennett]

On Tue, Mar 16, 2010 at 10:36 AM, orokusaki  wrote:
> It doesn't seem that the core team is interested in working on Model
> validation at the moment: http://code.djangoproject.com/ticket/13121
> (my failed ticket)

Stop right there and actually go back and *read* all the feedback
you've gotten, because right now you're just flat-out lying. Russell
has, on multiple occasions, asked you, begged you, and pleaded with
you to get proper discussion going on the things you've proposed.
You've refused and instead adopted a method of opening duplicate
tickets and screwing around with the metadata on existing ones,
apparently out of a desire to annoy as many people as possible rather
than get anything useful done.

If you'll actually pay attention to what others say and actually put
in the time to learn how the Django development process works, you may
be a lot happier with the results. If instead you just continue what
you've been doing, well, I for one will be happy to direct you to some
other framework that's willing to put up with such antics.



-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

-- 
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: Model validation outside of ModelForms.

[orokusaki]

Strong 1+

It doesn't seem that the core team is interested in working on Model
validation at the moment: http://code.djangoproject.com/ticket/13121
(my failed ticket)

The current thinking by the powers that be is that you cannot
introduce model-level validation enforcement without breaking the API
for existing users. This is simply not true.

With ValidationError propagating upwards from the model level,
ModelForm would need nothing to do with validation besides displaying
the errors to the user. This is the common sense approach to
ModelForms anyway, and the only people who would suffer from this
migration would be those who have hacked the core from within their
code (re-writing methods in their subclasses that shouldn't typically
be re-written).

If this were the case, you could build all of your data logic into the
Model and then an RPC API, a view, or the built-in Admin would all be
very DRY and work identically when using your model. Instead you have
to rewrite code all over the place and you cannot even abstract
correctly as their are too many leaks into the view layer (see
http://www.joelonsoftware.com/articles/LeakyAbstractions.html).

Michael

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

Call for sprinters for 1.2

[James Bennett]

Russ is about to put up a post on the Django weblog with the current
state of 1.2. There's been quite a bit of progress since the last
update, but there are still around 60 tickets which will need in-depth
attention before we hit the point of releasing 1.2; the remainder of
the tickets on the milestone are mostly trivial (documentation
updates, translation fixes and other minor issues).

To help get these tickets resolved (and 1.2 out the door), we'd like
to organize a 1.2 sprint either this weekend (March 20/21) or the next
(March 27/28), and put out a call for anyone who's willing and able to
join in. The focus will be entirely on the 1.2 milestone tickets, with
the goal of resolving as many as possible and getting to the 1.2
release candidate. So if you're interested and would like to help out,
please head over to the wiki page for the sprint:

http://code.djangoproject.com/wiki/1.2ReleaseCandidateSprint

and add your name and when you'll be able to sprint.


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

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