Malcolm Tredinnick said the following:
> I'm basically -0 on the change (maybe a bit more than that) and since
> it's not mountain-out-of-molehills month, I figure we can live with
> things as they are and not imposing unnecessary breakage on our
> userbase.
With respect, I think it should be
On Tue, 2007-12-18 at 01:12 -0800, SmileyChris wrote:
> http://code.djangoproject.com/ticket/2891 was marked as a wontfix by
> jacob after "discussion with Malcolm".
>
> Neither Collin or myself (or several others on IRC) can see a reason
> why that this would cause any big disruption.
How did
> http://code.djangoproject.com/ticket/2891 was marked as a wontfix by
> jacob after "discussion with Malcolm".
>
> Neither Collin or myself (or several others on IRC) can see a reason
> why that this would cause any big disruption.
>
> Mr Trier even mentions it on his blog today as an example of
On Dec 18, 4:07 pm, Justin Bronn <[EMAIL PROTECTED]> wrote:
> I added your patch to the ticket. It's much easier to submit
> attachments, etc. when you register:
>
> http://www.djangoproject.com/accounts/register/
Ah thanks; I got confused on code.djangoproject.com when I got an
apache auth
I added your patch to the ticket. It's much easier to submit
attachments, etc. when you register:
http://www.djangoproject.com/accounts/register/
Regards,
-Justin
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
I ran into dates prior to 1900 being unsupported while ago and
finally got around to working with it.
I attempted to attach this to Bug #1443 but got rejected as potential
spam. The patch is against today's SVN and the unittest suite works
against the sqllite3 backend. Unfortunately, MySQL 4.x
Gang,
I've updated the patch on #5361, so that it now includes a variety of
tweaks and updates that I've been working on since before the sprint.
Jacob's help during the sprint was great, but I've run across a
variety of other issues[1] since then, and I did my best to make
decisions that I felt
np ;)
>12/01/07 18:58:39 changed by jacob ¶
>* status changed from new to closed.
>* resolution set to wontfix.
>OK, Malcolm and I have discussed this IRL and decided that this
ticket will just break too many people's code. We should instead
change the documentation to not suggest that
On Dec 17, 7:32 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> I'd be -1 on introducing another setting for something so minor. The
> string view is just meant to be a snapshot, so maybe increase it by a
> little bit (100, maybe ... *shrug*). But it shouldn't need to be
> customisable by
On 12/18/07, Vinay Sajip <[EMAIL PROTECTED]> wrote:
> A reasonable approach would be that the media root for any app is
> conventionally /media/app_label. This is easily organisable under
> Apache/mod_python by having a single media location /media/ for which
> you do a "SetHandler None", then
On Dec 18, 6:01 pm, "Rob Hudson" <[EMAIL PROTECTED]> wrote:
> On 12/18/07, Vinay Sajip <[EMAIL PROTECTED]> wrote:
>
> > A reasonable approach would be that the media root for any app is
> > conventionally /media/app_label. This is easily organisable under
> > Apache/mod_python by having a single
On Dec 18, 5:37 pm, Vinay Sajip <[EMAIL PROTECTED]> wrote:
> The default setting for ADMIN_MEDIA is /media/. The doc on serving
Whoops, I meant ADMIN_MEDIA_PREFIX. Sorry.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
The default setting for ADMIN_MEDIA is /media/. The doc on serving
static media (under the "big, fat disclaimer") suggests using /
site_media/ for other (non-admin) media. The doc on mod_python
deployment suggests using /media/ for media in general, and mentions
that under the development server,
Sounds like a sensible cleanup to me.
Regards,
Jason
On Dec 17, 8:21 pm, Brian Rosner <[EMAIL PROTECTED]> wrote:
> I would like to propose splitting django.newforms.models. The reasoning
> behind this stems from the work going on in newforms-admin.
> django.newforms.models now consists of
On 12/18/07, Yuri Baburov <[EMAIL PROTECTED]> wrote:
> Unfortunately, not the first time I see that you guys wrong understand
> your users and their code :(
I'm sorry; I stopped reading at this point. If you'd like to try your
argument again, leave off the ad hominem attacks next time.
Jacob
On Dec 18, 2007 2:12 AM, David Danier <[EMAIL PROTECTED]> wrote:
> Correct me if I'm wrong, but doesn't this miss the big parts when
> writing your own auth-application. After adding this two methods the
> tables for LogEntry and Message still exist in the database, but are
> unusable. If you
>12/01/07 18:58:39 changed by jacob ¶
>* status changed from new to closed.
>* resolution set to wontfix.
>OK, Malcolm and I have discussed this IRL and decided that this
ticket will just break too many people's code. We should instead
change the documentation to not suggest that people
http://code.djangoproject.com/ticket/2891 was marked as a wontfix by
jacob after "discussion with Malcolm".
Neither Collin or myself (or several others on IRC) can see a reason
why that this would cause any big disruption.
Mr Trier even mentions it on his blog today as an example of a silly
I think I was just bitten by this. The model fields defined in
django.contrib.auth.models (and I assume other parts of django) use
django.utils.translation.ugettext_lazy to specify the label (or
another property from which the label is derired). The form field
objects generated by form_for_* and
Sorry, i forgot this in my previous mail.
> I'm not particularly attached to these method names, but adding
> methods on ModelAdmin, say, log_action() and send_user_message(), and
> having the object-saving code call those methods instead of directly
> handling logging and messages, [...]
> I'm not particularly attached to these method names, but adding
> methods on ModelAdmin, say, log_action() and send_user_message(), and
> having the object-saving code call those methods instead of directly
> handling logging and messages, would solve this pretty cleanly (and
> also add a
21 matches
Mail list logo
