Some thoughts on our security policy as we head towards 1.0

I like our security policy[1]. As security policies in the open-source world go, it's not bad. But it could be better, and I think that as we get closer to Django 1.0 it's increasingly important for it to *be* better. Currently the policy says that a security fix will "probably mean a new releas

Re: Trac error uploading attachment

On 1/18/07 8:12 PM, [EMAIL PROTECTED] wrote: I'm trying to add an attachment to a ticket: http://code.djangoproject.com/attachment/ticket/3099?action=new I'm getting the following error: Yeah, I'm getting that too. I'll try to fix it if I can figure out what's up. Jacob --~--~-~--~

Trac error uploading attachment

I'm trying to add an attachment to a ticket: http://code.djangoproject.com/attachment/ticket/3099?action=new I'm getting the following error: Oops... Trac detected an internal error: If you think this really should work and you can reproduce it, you should consider reporting this problem to th

Re: Proliferation of DB FieldTypes

How about a decorator over constructors? USZipCode = FieldWithValidation(CharField, [isUSZip]) How about this syntax? something like oldform style? USZipCode = CharField( validators=[isUSZip] ) --~--~-~--~~~---~--~~ You received this message because you are

Re: trac: please bring back 'reopen'

On Jan 19, 11:24 am, Michael Radziej <[EMAIL PROTECTED]> wrote: IMHO, it shouldn't go into stage "Needs Decision" before the information arrives. I'm not a fan of instantly closing tickets while waiting for information but I see the point Jacob/Micheal is expressing. It would be great to have

Re: trac: please bring back 'reopen'

On 1/18/07 4:24 PM, Michael Radziej wrote: The basic idea is (and this is *my* interpretation), we have enough tickets. We probably have more tickets than we can process, even with triaging. There's no use in keeping tickets when the reporter has lost the interest in helping with it. (Of course

Re: Proliferation of DB FieldTypes

Webda has a lot of localization information already compiled - http://webda.python-hosting.com/ Including, countries, areas (states, etc), languages, phone numbers. It already had Django modules so it could be a good contrib to add. I do agree that most of these are char fields and the FieldWit

Re: trac: please bring back 'reopen'

Hi all, Gary Wilson wrote: I would say a ticket should be closed as invalid only if there wasn't enough information in the ticket subject + description to understand what the problem is. Do you disagree about the "invalid" vs. "wontfix", or about closing? If it's the latter ... first, forge

Re: ANN: Upgrading code.djangoproject.com

Nice job guys. Should make things much more clear. Since the update I noticed that this page [1] no longer works. Thing is, it's the only one with a problem that I could find (not that I checked every page) and of course it is the one I wanted. [1]: http://code.djangoproject.com/browser/django

Absolute URL's in documentation

Hi, I was writting a document for Django's documentation (#3325) and just noticed that links between documents of the documentation are absolute, is this intentional ? If one would like to run his/her own mirror at home converting the .txt to .html he/she would have to rewrite all the URLs, not to

Re: Proliferation of DB FieldTypes

On 1/18/07, telenieko <[EMAIL PROTECTED]> wrote: ... On fields like USZipCode or USState and those which are **really** region speciffic could be put on contrib (why would somebody outside US want those fields? ie) we could end up with SpainRegion, CaribeanIsland... you get the idea. It seems

Re: Proliferation of DB FieldTypes

Hi, Some of those fields could, maybe, be solved on a way like the one I just submitted to #1636. Basically IPAddressField could have an option about whether it should or shouldn't accept cidr notation IP's as the field is **almost** the same it could be an elegant way to have both in one ;) On f

Re: trac: please bring back 'reopen'

Michael Radziej wrote: Jeremy Dunck wrote: > Michael, I see that ticket was closed as invalid because it needed to > pass tests. > > If I understand the triage process correctly, it should have been > marked accepted, but with has_patch=1 and patch_needs_improvement=1. Yeah, your're basically r

Re: Proliferation of DB FieldTypes

[EMAIL PROTECTED] wrote: Many of these have working patches and are ready to go, but I'm wondering if we want to proliferate the number of field types? I think that adding too many of these is just adding clutter ( e.g. EthernetAdress vs. IPAddress vs. CIDR etc ) and especially since a CharField

Re: ANN: Upgrading code.djangoproject.com

On Jan 18, 11:31 am, telenieko <[EMAIL PROTECTED]> wrote: Maybe the WikiStart could be locked down so newcomers don't get confused? It does not need to be changed that much ;) Or at least set some guidelines for it. It seems to get more cluttered by the day. I would like to see some of those

Re: ANN: Upgrading code.djangoproject.com

Maybe the WikiStart could be locked down so newcomers don't get confused? It does not need to be changed that much ;) On 1/18/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote: On 1/18/07, Jeff Forcier <[EMAIL PROTECTED]> wrote: ... > Anyway, don't know if the current blank-ness is because someone wa

Re: trac: please bring back 'reopen'

Hi Jeremy Jeremy Dunck wrote: On 1/18/07, Michael Radziej <[EMAIL PROTECTED]> wrote: Hi, somehow the reopen button went on vacation with the trac udate--can anyone call it back? It would be very appreciated by ticket #3320 ;-) (At least, I cannot reopen from closed/invalid) Michael, I s

Re: Wiki tampering

On 1/18/07 8:15 AM, Jeremy Dunck wrote: Perhaps the triagers should also get a non-committing apache auth to boost their no-spam karma? I've got enabling registration (logged-in users don't get spam filtered) on the todo list, but it's a little complicated (I've got it using Django's auth, w

Re: trac: please bring back 'reopen'

On 1/18/07 8:08 AM, Ramiro Morales wrote: It's me or the "type" field (defect, enhancement, ...) of a ticket is also missing?. We got rid of that field, along with a couple of other fields we don't really use. In this specific case, besides not using it, the line between "defect" and "enhan

Re: ANN: Upgrading code.djangoproject.com

On 1/18/07, Jeff Forcier <[EMAIL PROTECTED]> wrote: ... Anyway, don't know if the current blank-ness is because someone wanted to vandalize, 251 was vandal, 252 was removing the vandalism, but not restoring the original: http://code.djangoproject.com/wiki/WikiStart?action=diff&version=251 --~

Re: ANN: Upgrading code.djangoproject.com

Looks like someone's been futzing with the wiki frontpage, although I'm unsure if it's really intentional or not: it's currently blank, but when I tried to restore it to the last "good" version, Akismet complains thusly: Submission rejected as potential spam (Maximum number of external links

Re: Proliferation of DB FieldTypes

[EMAIL PROTECTED] wrote: Evening all, I've been digging through Trac and found that there's a number of tickets related to adding new database Field types: Is there any documentation on adding your own field type? This might alleviate the need to centralize some of the smaller field types.

Re: Schema Evolution branch?

On 1/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Michael Radziej wrote: > > In such an environment, central > > branches aren't needed; everyone with a copy of the source repository > > can branch it on their local system. Have you checked out SVK? ( http://svk.bestpractical.com/view/H

Re: trac: please bring back 'reopen'

On 1/18/07, Michael Radziej <[EMAIL PROTECTED]> wrote: Hi, somehow the reopen button went on vacation with the trac udate--can anyone call it back? It would be very appreciated by ticket #3320 ;-) (At least, I cannot reopen from closed/invalid) Michael, I see that ticket was closed as inva

Re: Wiki tampering

Jeremy Dunck: I got the raw markup of the untampered page: http://code.djangoproject.com/wiki/WikiStart?version=250&format=txt But when I tried to submit it, it was rejected as spam, though I have set my email using settings. Perhaps the triagers should also get a non-committing apache auth t

Re: Wiki tampering

I got the raw markup of the untampered page: http://code.djangoproject.com/wiki/WikiStart?version=250&format=txt But when I tried to submit it, it was rejected as spam, though I have set my email using settings. Perhaps the triagers should also get a non-committing apache auth to boost their no

Re: trac: please bring back 'reopen'

On 1/18/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: On 1/18/07 7:17 AM, Michael Radziej wrote: > somehow the reopen button went on vacation with the trac udate--can > anyone call it back? It would be very appreciated by ticket #3320 ;-) > > (At least, I cannot reopen from closed/invalid)

Wiki tampering

Grr, someone (named Anonymous) has gone and deleted the content of WikiStart and DjangoPoweredSites. I assume there is some way to revert to a previous version, but I can't see how to do it from the publicly available pages. Could someone more clueful than I am fix things back? (And I sinc

Re: trac: please bring back 'reopen'

On 1/18/07 7:17 AM, Michael Radziej wrote: somehow the reopen button went on vacation with the trac udate--can anyone call it back? It would be very appreciated by ticket #3320 ;-) (At least, I cannot reopen from closed/invalid) Very interesting - it looks like that action is being hidden fr

Apache 1.3 and mod_python 2.x support

Hi to all, I reworked Manuzhai's patch located at http://code.djangoproject.com/ticket/376 so it can fit to the current 0.95 version. I would like to ask trac's admins to reopen that item, since I can't find reopen box (probably I will need to log in :)) As you can find there, at my tests, it

trac: please bring back 'reopen'

Hi, somehow the reopen button went on vacation with the trac udate--can anyone call it back? It would be very appreciated by ticket #3320 ;-) (At least, I cannot reopen from closed/invalid) Cheers! Michael -- noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg - Tel +49-911-935

Proliferation of DB FieldTypes

Evening all, I've been digging through Trac and found that there's a number of tickets related to adding new database Field types: http://code.djangoproject.com/ticket/1466 USZipCodeField http://code.djangoproject.com/ticket/1636 CIDR Datatype http://code.djangoproject.com/ticket/1642 DirPathFi

Re: Patch to update django.utils.simplejson from 1.3 to 1.5

Hmm, the testsuite failed. Any help in figuring out is appreciated! It was a problem with the imports. Now should run fine with this: http://code.djangoproject.com/attachment/ticket/3320/simplejson_1_5_new.diff -- Lawrence http://www.oluyede.org/blog http://www.neropercaso.it --~--~

Re: Patch to update django.utils.simplejson from 1.3 to 1.5

Lawrence Oluyede: Is there any problem if the simplejson bundled with Django is updated with the last and just released version? I created a ticket with a diff: This should help people with Python 2.5 and Windows installation. I use python 2.5 myse

Patch to update django.utils.simplejson from 1.3 to 1.5

Is there any problem if the simplejson bundled with Django is updated with the last and just released version? I created a ticket with a diff: This should help people with Python 2.5 and Windows installation. I use python 2.5 myself but no Windows so

Re: ANN: Upgrading code.djangoproject.com

Hi, I'm being hit by a bug in trac. Whenever I try to attach a tar file, I get this traceback from the trac installation: Traceback (most recent call last): File "/home/trac/new-djangoproject-trac-test/trac/web/main.py", line 387, in dispatch_request File "/home/trac/new-djangoproject-trac-te

Disable field creation in forms for hidden model fields (#3247)

Hi there I'm trying to start the design discussion needed for #3247 concerning newforms. Currently if you add a field to your model with editable=False, e.g. created = models.DateTimeField(editable=False) then the field "created" isn't rendered in a form in the admin but it will still be rende