Re: contributing to django as a part of master thersis

be very curious to see a more thorough proposal/set of ideas (feature for the 1.4 or 1.5 timeframe?). All the best, - Gabriel Hurley -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-de

Re: [Django Design] Inline debugging

I'm not a fan of one-size-fits-all debugging tools. The last several replies clearly show the variety of preferences people have for the already-existing options. Adding a setting that allows you to replace the debugging module also implies the replacement modules support a common API, which may

Re: Contributing Guide Request For Input

I've added a patch to ticket #14401<http://code.djangoproject.com/ticket/14401> based on the contributions people made to the wiki. This is the final call for comments and review before it gets officially added. Thanks! - Gabriel Hurley -- You received this message beca

Re: Suggestion: a new "nature" field in Trac

I'm still in favor of adding the "needsinfo" resolution and would love to see that happen... I guess technically I could even do that one myself via Trac's web admin if we're all agreed on it. I'm ambivalent about adding the "ticket type" field back in, though. It can be useful, but it *is* an

Re: Your thoughts on the Secure Web Application Framework Manifesto

I so choose. Either way, thank you for providing an interesting resource. All the best, - Gabriel Hurley On Feb 21, 5:09 pm, Rohit Sethi wrote: > Russell, awesome feedback. Thanks for being candid. We are on the same > page that the manifesto is really not all that important in and

Re: psycopg2.OperationalError: could not connect to server

This list is for the development of Django itself. Please try asking your question on the Django Users list<https://groups.google.com/group/django-users> . All the best, - Gabriel Hurley -- You received this message because you are subscribed to the Google Groups "Django

"needsinfo": resolution vs. triage stage

In regards to #14702 , which so far has been a universally favored idea, there's one lingering issue: Do we want to implement it as a resolution (i.e. you close a ticket as "needsinfo" and the reporter reopens to provide the information) or as a triag

Re: "needsinfo": resolution vs. triage stage

Thanks for the input. The consensus is clear. #14702 is now closed! (as fixed) I wanted to close it as "needsinfo" just for the humor of it, but oh well. Enjoy the new resolution (and accompanying docs)! - Gabriel -- You received this message because you are subscribed to the Google Group

Re: Trac components cleanup

I'm not endorsing any specific set of changes here, but I can address the feasibility of making the changes in Trac: >From empirical testing on my own Trac installation (running 0.11 currently, Django is on 0.12) updates to components, resolutions, etc. all propagate correctly when edited throu

Re: CSRF Header broken on uWSGI

>From the information you've given I can't say what's causing your process to hang, but as to your other point about jQuery... yes, jQuery 1.5.0 had a legitimate bug that prevented headers from being properly set on AJAX requests. It was one of the reasons th

Re: Enhanced auth.User

I would further add that the goal of any refactor in this area is not to add a wishlist of enhancements to the existing User model (though that may happen in tandem), but to truly make the framework extensible/agnostic in a way which it currently is not. All the best, - Gabriel -- You re

Re: Django 1.3: running test suit

The extra object is in the initial_data.json fixture which is loaded automatically. If you're not seeing that object than something is wrong with your initial_data fixture loading. - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" g

Re: Proposal: switch to HTML5 for bundled templates

While on a personal level I agree wholeheartedly about moving to HTML5, I do have reservations about it from the perspective of Django's "enterprise" customers (AKA the ones with legacy and bureaucratic issues). Thankfully we don't have major backwards-compatibility issues to deal with from a f

Re: Proposal: remove compatibility for old signing functions

+1, this seemed kludgy to me and had potential insecurities as it was. You're only as strong as your weakest link, right? All the best, - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to dj

Re: Trac components cleanup

I can work on it late tonight (about 6-8 hours from now) if no one else gets to it. All the best, - 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-developers@googlegroups.com. To u

Re: Proposal: switch to HTML5 for bundled templates

Switching to the HTML5 doctype won't hurt IE6 rendering (having dealt with this myself several times). To the best of my knowledge--from my own tests and third-party sources--using the new input attributes also doesn't hurt IE6. However, if we start delving deeper into HTML5 and using the new HT

Re: State of X-Sendfile support?

FWIW, I vaguely recall how the last thread on X-sendfile and the files API got conflated (derailed?) and as far as I understood it then and as far as I understand it now, they're related only because some backends (which we currently don't directly support) are difficult to work with without suc

Re: Trac components cleanup

The component re-organization is done now, as per Julien's (and Jannis') suggestions above. I even re-categorized the 84 tickets that were in "Contrib apps" into their new separate contrib.foo components (thank god for Trac bulk modify privileges!). The organization definitely makes more sense

Re: Suggestion: a new "nature" field in Trac

+1 on blocker being a severity, -0 on "other" as an option here. +0 on the others. Happy to donate a couple hours reviewing a chunk of tickets in a coordinated way if we decide to do that. - Gabriel -- You received this message because you are subscribed to the Google Groups "Django devel

Re: [5-for-1] Review request

I noticed the "TODO" on the bottom of that page you linked... if you actually want to write something up for the docs about reviewing tickets (based on the discussion that's happened on the list the last few days) I'd suggest adding it to the /docs/howto/contribute section. Feel free to ping me

Re: FloatField will not handle infinity values (Ticket #4287)

This seems to me like a problem best-solved by adding another attribute to BaseDatabaseFeatures so that DBs which don't support infinity can fail loudly, obviously, and preemptively. That make sense? - Gabriel -- You received this message because you are subscribed to the Google Groups

Re: math tag

This is a case where there's nothing stopping anyone (as far as I can see) from creating such a tag as an external library. If it garners significant community support and has numerous compelling use cases, then it would be a candidate for inclusion in trunk. If, in developing it, there turn ou

Re: PatchHammer 40,000

That should be relatively trivial to hook up remotely via the XML-RPC API, similarly to the script Jacob posted here: https://gist.github.com/933116 - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send

Re: pure sql fixtures for tests

This seems antithetical to the design goals of Django's ORM (e.g. *not* being an interface for SQL but an abstraction layer for managing objects). While it may not be as pretty to execute your raw SQL in your setUp method, that seems like the right way to handle cases of specialized SQL such as

Re: Proposal: Adding UI and UX fields to Trac

A single flag for "UI/UX" would be my first choice, with just "UI" being second. Differentiating the two isn't going to produce a lot of useful information at this juncture. Certainly fine with me to go ahead and add something for it, though. - Gabriel -- You received this message because

Re: Form Rendering API Proposal

I just want to quickly add a second mention for the importance of being able to control row-level groupings of fields, as well as row-level attributes such as classes. It's a problem I've run into many times and would love to have included in the new form-rendering solution. All the best,

Re: is it time to start deprecating parts of contrib

+1 on deprecating databrowse. Dead code should be excised. As for webdesign, why not roll the one piece in it (the marginally-useful lorem tag) into the main library and deprecate the hook in contrib? -0 on deprecating formtools. For the sake of argument I could see admindocs being deprecated a

Re: django messages framework

I'm a fan of the idea, with the caveat that it can't break any backwards-compatibility with the current syntax. As such, that could either entail reworking the current methods that add messages to accept a template string as a keyword argument (and making the positional "message" argument optio

Re: Custom transform in django docs

Definitely in favor of removing it. I've run into that before and been frustrated by hacking around the strange indentation. - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://g

Re: Sane defaults for Startapp and Startproject

Thanks for the suggestions, Rich... I'll try not to repeat what others have said, but have a couple notes to add: should create ./static, ./uploads and ./newproj and ./newproj/ > templates > I could get behind static, and *maybe* even templates, but absolutely not uploads. I would argue again

Re: Sane defaults for Startapp and Startproject

I think there is sufficient interest in the idea of a "how to organize your Django project" page in the documentation that it would be worth beginning work on a patch for one, much in the way that the "How to contribute to Django"/"Spirit of contributing" page got started. That means: 1. Ope

Re: Deploying Feature in manage.py

Having done deployments of varying scales and having spent a lot of time with Fabric, as well as some with Chef, Puppet, etc. I don't think there's any way we can build a tool that will meet any but the absolute simplest of needs without unnecessarily re-inventing a lot of wheels. However, if y

<    1   2