Can a core dev. take a dig through the edit_inline code?
Hi Djangonauts, I've gone on a bit of a triage rampage tonight (..and this morning), and there are many tickets regarding edit_inline bugs, and there are *many* more that are marked as dupes. If someone can fix this up a bit, this will clean out a lot of bug (and some are quite serious - leading to data loss). Here's a quick tally: weird interaction with auto_now_add on update raising an exception: http://code.djangoproject.com/ticket/2717 Multiple FileFields & edit_inline interaction overwriting preceeding files: http://code.djangoproject.com/ticket/2413 http://code.djangoproject.com/ticket/792 interacting with a specific unique_together ordering: http://code.djangoproject.com/ticket/2470 http://code.djangoproject.com/ticket/526 http://code.djangoproject.com/ticket/2415 or just unique: http://code.djangoproject.com/ticket/565 edit_inline deleting stuff: http://code.djangoproject.com/ticket/3425 validator issues: http://code.djangoproject.com/ticket/265 http://code.djangoproject.com/ticket/1690 Manipulator allowing "stealing" of related objects (prob. just a design choice): http://code.djangoproject.com/ticket/3145 Multiple Foreign Keys: http://code.djangoproject.com/ticket/1939 (with another 3 or 4 tickets marked as dupes) Not using a sensible default state: http://code.djangoproject.com/ticket/2159 Causing KeyError: http://code.djangoproject.com/ticket/2434 & OneToOne fields: http://code.djangoproject.com/ticket/24 Ignoring things with core=True: http://code.djangoproject.com/ticket/2724 Non-working prepopulate from: http://code.djangoproject.com/ticket/957 A possible better way of doing things (which Adrian says is "fantastic"): http://code.djangoproject.com/ticket/2248 --Simon G. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: app completion in django_bash_completion - testing please
Hi Rob, This looks good, thanks. I've triage'd that ticket on to "Ready to checkin" and we'll let one of the core developers check it out and see if it meets their approval :-) -Simon G. On Feb 24, 6:04 am, "Rob Hudson" <[EMAIL PROTECTED]> wrote: > I re-opened bug 1240 and added my patch > there:http://code.djangoproject.com/ticket/1240 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Generic view for serialized queryset
Hi dchandek, This looks like an interesting idea - could you create a new ticket for it at djangoproject.com, so it doesn't get lost? Thanks, Simon G. On Feb 24, 9:44 am, "dchandek" <[EMAIL PROTECTED]> wrote: > FWIW, I didn't see anything like this in the distribution, and it > might be useful ... > > def serialized(request, queryset, format, mimetype=None): > """ > Serialize queryset in specified format and return via HTTP > Standard mimetype for format can be overridden with provided value > """ > from django.http import HttpResponse > from django.core import serializers > content = serializers.serialize(format, queryset) > if mimetype is None: > if format == 'xml': > mimetype = 'application/xml' > elif format == 'json': > #http://www.ietf.org/rfc/rfc4627.txt > mimetype == 'application/json' > return HttpResponse(content=content, mimetype=mimetype) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: multiple-db-support branch
Please add them to Trac, as it's a good idea to keep an eye on them. There's a few multi-db bugs/patches out there, e.g.: http://code.djangoproject.com/ticket/3613 http://code.djangoproject.com/ticket/3301 If one of the trac-admins can add a multi-db value to the "version" field in Trac, that would be great. Otherwise, just mark them all as "other-branch" and put [multi-db] in front of the ticket title like the others have. --Simon G. On Mar 1, 6:39 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > I've currently uncovered two bugs so far with this branch... but am > unsure where to go to enter them in for tracking. I've got a ton of > stuff working, and these popped up when I was trying to do a few > complicated things. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Bug in Admin's Change Password form
Hi Todd, Can you drop by code.djangoproject.com and create a ticket for this, so we don't lose trac (sorry) of it. Thanks :) Simon G. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Bug in Admin's Change Password form
I thought #3579 was more of a generic thing, but well spotted Gary! -Simon On Mar 3, 5:21 pm, "Gary Wilson" <[EMAIL PROTECTED]> wrote: > On Mar 2, 6:38 pm, "Simon G." <[EMAIL PROTECTED]> wrote: > > > Can you drop by code.djangoproject.com and create a ticket for this, > > so we don't lose trac (sorry) of it. > > Actually, we already have one:http://code.djangoproject.com/ticket/3579 > > I have also referenced this thread in the ticket so that whoever does > try to fix it doesn't miss this case. > > Thanks Todd. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Trac vandalism
Can someone revert http://code.djangoproject.com/wiki/DjangoPoweredSites to the version 110, someone (220.227.72.2) deleted all the content and I can't replace it (too many links, Akismet thinks it's spam). We've been getting a few of these pop up recently, so it would be a good idea to block these ip addresses before the spam bots work out how to crap all over everything: http://code.djangoproject.com/ticket/3650 http://code.djangoproject.com/wiki/SnakesAndRubiesTranscript?action=diff&version=6 http://code.djangoproject.com/wiki/DjangoPoweredSites?action=diff&version=108 --Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Trac vandalism
Thanks Malcolm. --Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: About triaging etc.
I've started http://code.djangoproject.com/wiki/People and listed a number of the core devs (the ones that came to mind at least - I'll dig through AUTHORS later and add the rest), and the triagers. Anyone else? --Simon G. On Mar 6, 10:23 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > Agreed that we need to be more clear about who these people are. > Anyone want to create a "Who's who of Django" page on the wiki to keep > track of everyone? I'll make one later on if nobody gets to it. > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Upcoming Django release, and the future
#3625 ( http://code.djangoproject.com/ticket/3625 ) looks like a good candidate - it's a Python 2.3 issue with rsplit in the test system. It's been reported three times, so people are definitely running into it. 3625 has a simple patch to fix this. --Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Tickets on send_mass_mail functionality (multipart/encoding/TLS/BCC)
Good Evening Djuggernauts, I've spent some time looking over the email related tickets in Trac, and think I've got them sorted out a bit. I'm hoping to spur some discussion on some of these, so here's a brief recap. We currently have requests to: #1541 - Add Multipart Message capability to mail This ticket's first birthday is creeping up. There's a patch here that adds a safe method for sending multipart messages. Jacob has said this is great, but it needs docs. HOWEVER, Gary Wilson's pointed out that we're getting a rather ugly data tuple going on, and created 3366 -> #3366 - objectify send_mass_mail parameters This aims to clean up the send_mass_mail arguments by plugging them into an object. This looks fairly sensible, and has a patch, but has some backwards incompat. issues. This needs a design decision - and if it's "yes", then the other tickets will probably need to be rewritten to take this into account. #2007 - Enable email sending in a non-default encoding. A pure feature request to add a new setting that could override the charset that emails are sent in. No patch, and I'm not sure how useful this would really be. Let me know if I'm wrong here. #2897 - Support TLS This has a simple patch, and could add some nice functionality. Adrian wontfixed it 6 months ago, but it's been reopened and a couple of people are arguing that it's a good feature. [yes/no]? #3307 - Add BCC to mail framework. I've renamed this ticket from what it used to be. This originally had two issues - one which overlapped with #1541, and the other this BCC request. There's a patch here with adds a parameter to send_mass_mail to suppress the recipient list (i.e. by BCC'ing them), but Gary Wilson's argued that it's more logical to have two parameters: recipient_list & bcc_list. So - this just needs a design decision on what path to take (if any). #3605 - Simple patch to give content-type definition for sending html mails. This one looks like a quick design decision. Tickets: http://code.djangoproject.com/ticket/1541 http://code.djangoproject.com/ticket/2007 http://code.djangoproject.com/ticket/2897 http://code.djangoproject.com/ticket/3307 http://code.djangoproject.com/ticket/3366 http://code.djangoproject.com/ticket/3605 Comments? --Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Possible enhancement: CGI-style population of os.environ
This sounds like a good idea, and if everyone else is doing it... It might also make #2407 cleaner (CGI Support)- some of the comments there are stating that you need to load PATH_INFO etc into the env to get it running properly. http://code.djangoproject.com/ticket/2407#comment:14 --Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Move tutorials to own page on DjangoResources?
Does anyone object/disagree if I move all the tutorials off the DjangoResources page (1), to a new page (2) to give them some more room to 'breathe'? I'll take a crack at categorising them too - pre- MR, components, etc. (1) http://code.djangoproject.com/wiki/DjangoResources (2) http://code.djangoproject.com/wiki/Tutorials --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newsessions
I actually passed this onto the security mailing address, as I thought it was better to be safe than sorry. Adrian's response was that tying things to the IP address is not a good idea (for the reasons that others have stated in this thread). One thing that I would like to suggest is that we do link the SID to a user-agent (see Chris Shiflett's excellent article on this at [1]), as this provides some protection (-via-obscurity) against these collisions, since the attacker not only needs to get a valid SID, but match it to the correct UA string. There's also no reason for a "normal" user to change UA strings without needing to login again. This can easily be added to the existing session framework by adding it to the hashing --Simon [1] http://shiflett.org/articles/the-truth-about-sessions --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: python-MySQLdb-1.2.1p2 not in debian sarge
[Option 4] - Raise a warning for MySQLdb's that ARE 1.2.1 but not 'final', (i.e. "Your version of MySQLdb is 1.2.1 gamma, Django would prefer 1.2.1 final. Please upgrade (see docs page for why"...) and document this. Keep the failure on anything less than < 1.2.1. & I just wanted to say that I'm + 1 On acknowledging Andy Dustman's work too. Maybe there should be a "huge thanks" section of AUTHORS for this sort of stuff. --Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Support for a binary storage field?
Hi folks. Digging through the tickets, it appears we have a few near-duplicates requesting some form of binary storage inside the database. Whilst I'm -0 (RDBMSes are not for binary data!), but I can see the use for them in some circumstances (#2417 lists a few), and these are likely to be a fairly commonly requested feature. We have an ancient ticket at #250 from Jacob detailing the need for this, #652 wants an upload-to-database facility for Image- and FileFields. Finally, there's a patch in #2417 which implements a small binary field which JKM says is "very very good". Marc Fargas has added docs, etc. So - if we do want a BinaryField we could use #2417 and make it suitable for larger binary stores (e.g. the VARBINARY used for MySQL has a max length of 255 bytes - perfect for the small bin. chunks wanted in #2417, but not for larger data), and then hook it up to Image/FileFields for #652. An alternate solution is to check in #2417 for small binary chunks, and then hold 652 back until we decide if we want a LargeBinaryField for large binary chunks suitable for file uploads. Relevant Tickets: http://code.djangoproject.com/ticket/250 http://code.djangoproject.com/ticket/652 http://code.djangoproject.com/ticket/2417 Cheers, Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Support for a binary storage field?
Ok, my reading of the general consensus here is that everyone thinks a BinaryField is a good idea, so I've kept #2417 as accepted, with the patch needing a few improvements. The second issue - a (say) BinaryStorageField for large bin. data hooked up to Image/File uploads seems to be one that's wanted by a few people, and strongly disliked by a number of others (about 50/50), so I've marked it as wontfix for the time being. As Todd suggested, it shouldn't be too hard to implement yourself if you do need this functionality, however, if someone wants to write up a proposal / initial code for this, then please do so and re-open #652 -- Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Criteria for localflavour
Hi all, We're starting to see some localflavour patches drift in, which is great (e.g. it: #3866, fi: #3847, ja: #3715 ). However, we should be briefly documenting these - it could simply just be a list of what's in there so far. I'll work up a patch for this sometime, but just wondered where to put it. Currently django.contrib.localflavor is listed in the "add_ons" docs, but should the details be in the internationalisation docs (either way the i18n docs should mention localflavour), or could this have its own doc file? --Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Criteria for localflavour
I've had a first pass at documenting these in #3883 - any comments? http://code.djangoproject.com/ticket/3883 --Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Localflavors: request for developers and triagers
Hi Malcolm, Should ALL the strings in these be unicode objects, even if they don't have any extended characters? I'm looking at the already checked in fr localflavor, and these are all ASCII with the respective file set to UTF-8 with that -*- thing (what is that called?), there's also a Brazilian one that I've marked as ready to go, but only the strings with non-ASCII chars are unicoded. --Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: OneToOne fields - why not?
Hi Alex, I marked that as invalid since (as I understand it), we're trying to get rid of edit_inline. However, I'm not sure how far off the admin- newforms rewrite is, and it's probably a good idea to get this simple fix in anyway (especially if people are having problems with). --Simon. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: r4941 - django/branches/newforms-admin/django/contrib/admin
This was reported way back in the triple-digit days: http://code.djangoproject.com/ticket/987 I took a couple of stabs at it a while ago. I patched HttpResponseRedirect to prepend the domain to the current site specified by settings.SITE_ID, as long as it's not the default "example.com" (anyone using example.com is screwed though). However, looking over it now, I'm not sure if it'll always work, and should use urljoin instead of os.path.normpath. It also has the issue of requiring a DJANGO_SETTINGS_MODULE. --Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Backwards incompatible changes
I believe that the plan for 1.1 is to rewrite Django in Lisp or Haskell. Or is Scheme the cool one now? j/k --Simon On Apr 8, 4:34 am, "Noah" <[EMAIL PROTECTED]> wrote: > I'm worried about a trend I've seen before in other frameworks etc. > They start off easier to use and over time get more and more > generalized and then become so general and so academically 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-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Add note about removing egg to install docs?
Hi Jay, Someone reported that issue a few weeks ago, and I added a quick patch for this here: http://code.djangoproject.com/ticket/3830 It can probably be enhanced beyond that though. --Simon On Apr 11, 4:43 am, "Jay Parlar" <[EMAIL PROTECTED]> wrote: > Recently in [1], someone ran into a problem after installing 0.96. > Namely, the 0.95 egg was still on the system, and overriding the 0.96 > install. > > Could we maybe get a note in the install document to help people out > with this? I forsee lots of people asking about this in the near > future, as more people move their installs to 0.96. > > [1] :http://groups.google.com/group/django-users/browse_thread/thread/4340... > > Jay P. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: #3527 - better debug traceback with code executing...
My preference would be to have it as either a package in contrib, or a third party package that users can install. I don't know how easy it would be to override Django's default debug handler but shouldn't be too hard. This way we don't have any on-by-default situations, and it should be fairly safe since it'll have to be installed by a developer (plugged into settings.INSTALLED_APPS) , and most people don't develop with the same settings file that they run a production site off. --Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Escaping in templates...
This is one of those issues which is never going to please everyone. So - I've started a list of the various proposals (1), and could you all add any other proposals to this page, along with any pros/cons, and vote on the one(s) you prefer. This way we can get some idea of what a consensus view might look like --Simon [1] http://code.djangoproject.com/wiki/AutoEscapingProposals --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Escaping in templates...
Sorry - I just skim read the discussions on it in "AutoEscape" and "AutoEscaping Alternative" where that was mentioned. Wasn't making any value judgements :-) --Simon On Apr 18, 2:49 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Tue, 2007-04-17 at 05:00 -0700, Simon G. wrote: > > If you're going to make a page like that, perhaps leave out the truly > subjective judgements like "magic" (a poorly defined term at the best of > times). Aside from the fact that I totally disagree with the claim (and > looking back at all the previous threads on this nobody's ever mentioned > the word except when talking about some alternative proposals), it > doesn't really add anything to the value of such a list. > > Thanks, > Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Templates: short comments {##} eats text
A patch, some docs and a few tests would be most welcome. --Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: The locmem patch and development progress
Evening all,
Speaking as a triager, I originally thought that an "easy-fix"
category would help solve these issues.
However, after doing quite a bit of ticket twiddling, these easy fix/
low hanging fruit don't hang around very long anyway. The tend to get
closed pretty quickly, even without triage (i.e. the core developers
seem to find them easily). Otherwise, I generally slot them into
"Ready for Checkin", if it's a few lines/simple bug fix thing that
doesn't need much discussion, and they get dealt with from there.
It might be nice, however, to have some way of flagging tickets -
there's a few tickets around that are RTC, have patches but have been
sitting around for months. it's hard to tell if this is because
they're forgotten, or someone's pondering them, or they need work, or
no-one's had the time to check them in. This locmem one is a case in
point here.
Maybe we could tag these somehow ("outstanding"?) so that the next
time a dev. gets some ticket time, they can glance over them and give
some feedback (wontfix, pls. improve patch, will-do-it-when-I-have-
time, etc).
--Simon G.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: The locmem patch and development progress
-1 What's the benefit of that over our current system where 0.96 is stable (except for major security fixes), and the active development is going on in trunk? This has been documented: http://www.djangoproject.com/weblog/2007/apr/06/changes/ - people should be using the 0.96 release on production websites. SVN is for development. Don't get me wrong, I certainly don't want to scare of anyone who wants to contribute, but I don't see that helping. We've already got a fairly complicated repository (with branches out the wazoo), and I think it'll just complicate things even further without giving any benefits. --Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
MEDIA_URL template tag/context processor/etc again
Evening all, There's been a long history of people asking for some way of easily using the MEDIA_URL setting in templates. At a quick glance, I get #1278, #3818, #2532, and #4105. These have all been marked wontfix, and I closed this last one to match. The reasoning for the wontfix is that this leads to a slippery slope of adding everything to the context and it's also quite easy to implement this on your own. However, given the frequency of this request (I've seen it raised a few times in django-users too), I figured I'd ask if core's still against this, or whether we want to accept one of these. --Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Merge some branches in before 1.0?
Just thinking out loud here - We've warned people off using the svn version to run production sites because of the post-1.0 code breakage that's going to be happening. So, we don't need to worry as much about stability of trunk, since 0.96 is the stable, recommended version. Therefore, why don't we get some of these branches merged in (once newforms-admin and unicodisation are sorted out), and let people get onto testing them? There are a number which look so close (Oracle, FullHistory, GenericAuth), but they don't seem to be getting any attention from the wider community, which I think they would if people didn't have to switch branches to get them. I know the reason that they've been left out is that they no-one's stepped up to maintain them, but once people start using them, then we'll see tickets and patches start to come in for them, and generate interest about them. Comments? --Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Tips on building a unit test for a ticket
... and while you're working out how to do it, it would be good to write it up for future reference :) (see: http://code.djangoproject.com/ticket/4223) --Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Unicode + memcache = bug
#4845 is probably related here in some way, giving this traceback: PythonHandler django.core.handlers.modpython: MemcachedStringEncodingError: Keys must be str()'s, not unicode. Convert your unicode strings using mystring.encode(charset)! There's a few patches there which force the keys to ASCII, but this may not be the best solution. --Simon [1] http://code.djangoproject.com/ticket/4845 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: wiki coordinator position
I can help too - I generally keep a close eye on the timeline to monitor any changes (i.e. spam) but it'd be great if there was more activity in the wiki and a few people who'd keep things in check. Is it easy to give out permission to delete attachments (often the spam consists of attaching some html doc. full of links to a wikipage) etc. -Simon On Jul 25, 11:52 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote: > On 7/24/07, Scott Paul Robertson <[EMAIL PROTECTED]> wrote: > > > Since I'm throwing out the idea, I'm willing to do this. Is any one else > > interested? > > This would be fantastic. It gets a big +1 from me. > > Adrian > > -- > Adrian Holovaty > holovaty.com | djangoproject.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-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Best Practices to Make your Apps Portable
There is a wiki page on this sort of thing: http://code.djangoproject.com/wiki/DosAndDontsForApplicationWriters ...but it hasn't been updated in a while. If anyone comes up with useful things, could you (or them) update that page? Thanks, Simon On Jul 25, 11:41 am, Sebastian Macias <[EMAIL PROTECTED]> wrote: > I posted this on django-users so I won't post the same here but I > thought the actual framework developers might have excellent feedback > on this. > > This is just an invitation to participate in django-users thread. I'm > sure this will be very useful to many people moving to django from > ruby on rails and php mvc frameworks. > > The thread is here: > > http://groups.google.com/group/django-users/browse_thread/thread/ab9e... > > Thanks, > > Sebastian Macias > digital-telepathy inc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Is it possible to add the docs to the test framework to check for ReST errors?
Hi all, Every so often we get a few tickets popping up about ReST errors in the docs. I've just patched one (#4995) where some hideously glaring mistakes like, say, missing a space after an asterisk, or one too few empty lines caused nasty error messages like: testing.txt:584: (WARNING/2) Inline strong start-string without end- string. testing.txt:584: (WARNING/2) Inline strong start-string without end- string. testing.txt:687: (ERROR/3) Unexpected indentation. testing.txt:690: (WARNING/2) Block quote ends without a blank line; unexpected unindent. testing.txt:697: (WARNING/2) Inline literal start-string without end- string. I was wondering if it was somehow possible to add the django docs -> ReST generation stage into the test framework to catch these before they get committed? Comments? --Simon [#4995] http://code.djangoproject.com/ticket/4995 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Best Practices to Make your Apps Portable
Excellent, thanks! --Simon On Jul 28, 5:47 am, Sebastian Macias <[EMAIL PROTECTED]> wrote: > I just added it to the wiki: > > http://code.djangoproject.com/wiki/BestPracticesToWorkWith3rdPartyApp... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django Success Stories
Great idea! > 1) Set up a page on the wiki with instructions and suggested outline > of a success story. > 2) Post a "Call for Success Stories" somehow, maybe via the weekly updates. > 3) Keep an eye on the page and linked pages. 4) Politely ask some of the big Django sites if they could answer 5 or 6 questions (e.g. pownce, tabblo, etc) If you get a few "big" names in there, then others should follow. --Simon G. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
