Re: How many Django web pages does it take . . .

FWIF, the code that generates that message is here: https://code.djangoproject.com/browser/django/trunk/docs/_ext/djangodocs.py#L84 Feel free to open a ticket if you like. All the best, - Gabriel -- You received this message because you are subscribed to the Google Groups "Django

Re: Proposal: Logout user when they change their password.

Options 2 and 4 from that list both involve database-level changes, and thus aren't feasible (our lack of schema migration tools being the biggest problem). Of those, I'd go for option 3 as well. We definitely don't want to store the full hash in the session for obvious security reasons, but a

Re: Sprint in San Francisco

I'll be there as well! Either set of dates works for me. - 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://groups.google.com/d/msg/django-developers/-/hCK2OwboH40J. To post to

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

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.

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

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

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

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

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

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: 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,

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

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: [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

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

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

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

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

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

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

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"

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

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

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

"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

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

Re: Your thoughts on the Secure Web Application Framework Manifesto

Either way, thank you for providing an interesting resource. All the best, - Gabriel Hurley On Feb 21, 5:09 pm, Rohit Sethi <rkli...@gmail.com> wrote: > Russell, awesome feedback. Thanks for being candid. We are on the same > page that the manifesto is really not all that import

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: 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 becau

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

Re: contributing to django as a part of master thersis

s (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-developers@googlegroups.com. To unsubscribe from this group, s

Re: Interested in contributing to Django

Hi Vivek, It's great to hear you're interested in contributing! This year's GSOC is just getting underway and while Django will likely participate as it has in years past, we're not quite at that stage yet. However, if you're serious about GSOC you'll have a much better chance of being

Re: contrib.sites and multitenancy

On Wednesday, January 19, 2011 12:01:57 PM UTC-8, Carl Meyer wrote: > > Contrib.flatpages is an example > of this -- the flatpage model has an FK to Site, so it doesn't make > sense for flatpages to call a method which might return a Site object > or might return something else. It needs a real

Re: Status of InstalledAppsRevision, soc2010/app-loading branch?

I haven't been tracking it closely, but last I heard on the subject is that it's on target for the 1.4 release cycle. So basically once we get 1.3 pushed out (and have a little rest) that'll be towards the top of the heap to be wrapped up and worked into trunk. There's almost certainly still

Re: contrib.sites and multitenancy

I would be more in favor of seeing a new setting to configure `get_current_site()` than seeing the existing `SITE_ID` setting shoehorned into a new purpose (and being permanently misnamed for legacy reasons). For the sake of allowing complete customization of the site lookup process I suppose

Re: Customizable Separator for slugify

I did actually just come up with two problems involved in having a customizable separator for slugify: 1) SlugField would also have to take a parameter to define the separator so that there wouldn't be inconsistencies in the output of SlugField and slugify. This seems like it would be a big

Re: Customizable Separator for slugify

Adding Yet Another Setting doesn't seem like much of a solution here. To the original poster's question I'd say that using anything but dashes for slugify would be very uncommon, but I don't see any reason why the slugify filter *couldn't* take an optional parameter to define what token should

Re: Regressions in 1.2.4

On Thursday, January 6, 2011 6:29:32 AM UTC-8, James Bennett wrote: > > It'd also be a major > maintenance/bookkeeping headache and, I think, *more* likely to result > in us accidentally crossing the streams while trying to keep track of > what goes on in which branch. > I have the same concern

Re: Style guide for section headers in docs?

And that's what I get for having an MLA reference sitting on my desk... - 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,

Re: ForeignKey with null=True

I'm in favor of the patch you've provided, Luke. Raising an exception seems like the best option here to me. While it *is* a logical error to get the related objects of an unsaved instance, the current behavior seems buggy and (as Ian Clelland points out) it can be potentially harmful. FWIW,

Re: Purpose of constant_time_compare?

You wanna hand over your paycheck now, or later? :-) I know someone with a functional white-hat timing attack script sitting on their laptop. They've been honing the statistical analysis to get the number of data points needed down to a less noticeable size, but the technique can already be

Re: Documentation style guide hint for section headers?

Agreed with Alex. I brought this up on IRC a month or so ago, and the (small) consensus was that it'd be great to have the ":real markup:" generate TOC entries the way we want it to, but that doing so involves hacking Sphinx (or at best writing a plugin for it) and nobody was ready to jump into

Re: Relation between models of different applications

Hi Alex, Neither of the ideas you mentioned (making auth.user more extensible/ replaceable and improvements to app loading) are new to the Django community. In fact, both were candidates for last year's Google Summer of Code. The app loading project even got accepted and had a good deal of work

Re: RFC: Add a "needinfo" state to triaging

> >> Example workflow: > > >>  * Alice creates a ticket, with an incomplete patch (no tests, > >> incorrect implementation) > >>  * Bob reviews the patch, marks it "Accepted, needs tests, patch needs > >> improvement" > >>  * Alice updates the patch, adding tests (but not changing the > >>

Re: RFC: Add a "needinfo" state to triaging

Bear in mind that this is a *very* old Trac installation... ;-) I don't have access to that server to see if the TracAdmin module is current enough to support the "resolution add " command. If so, that'd be the easy way. If not, like Daniel said, it's straight to the DB! - Gabriel On Nov

Re: RFC: Add a "needinfo" state to triaging

> Maybe trac can be improved in this respect by notifying > reviewers when tickets that they have closed, or accepted, or provided > feedback on, are updated. In my experience Trac already does that... when a ticket is changed (by anyone), the reporter, the owner, anyone on the cc list, and

Re: RFC: Add a "needinfo" state to triaging

Having recently set up a Trac installation for another project, I can tell you that making the actual change will require some hacking in the trac.ini file. There's no way to do it through the admin. All the best, - Gabriel On Nov 16, 7:02 am, Luke Plant wrote: > On

Re: RFC: Add a "needinfo" state to triaging

I like this idea for an additional reason: I look at the Django timeline regularly, but I have ticket detail changes filtered out. Therefore I *don't* see changes like "unreviewed" -> "accepted", etc. I do, however, see ticket status changes (closing, reopening, etc.). Thereby these kinds of

Re: IP addresses in docs.

> Hmm, I don't agree. They are not 'values' in the Python sense - if I > type 127.0.0.1 at a Python prompt I get a syntax error. They are no more > values than integers and floats (less so, by the above definition), and > we don't put any special markup around numbers. They would become values >

Re: making URL resolving/reversing gradually more flexible

> I'm not sure how open the core devs > are to non-core devs poking around in core parts of the framework > though. Anyone and everyone is welcome to write patches for any part of the framework! There's no sacred portion that only a core dev can touch. It sounds like you've given thought to the

Re: IP addresses in docs.

IP addresses definitely don't belong in plain text since they're a value... so that option can be ruled out. Between the other two options, I'm torn: I think that using the ``"some_value"`` notation (quotes inside an inline code block) breaks the visual flow for what's usually an obvious

Re: Ticket #7817: Extending "with" and "include" tags.

;. Either one gets the job done and I'd gladly accept either as they both solve the same problems. Thanks! - Gabriel On Nov 10, 1:36 am, Jannis Leidel <jan...@leidel.info> wrote: > On 10.11.2010, at 09:20, Gabriel Hurley wrote: > > > > > > > > > > > In a fi

Re: Ticket #7817: Extending "with" and "include" tags.

In a fit of coincidental timing, I was just being frustrated by this very issue with inclusion tags today. I'm +1 on supporting kwargs with "=". It is in fact *more* familiar to someone who works with HTML to be able to assign attributes in arbitrary order, for example: http://example.com;

Re: Call for review and comment: #7539 (ForeignKey on_delete)

> Another documentation-related question I have; is it necessary to mark > each passing referencing (and link) to on_delete with the version- > added marker? I went back and forth, and eventually decided against > it, for these reasons: (1) The passing references don't provide enough > info to use

Admin sends out potentially harmful m2m_changed signals

I'd like to call attention to ticket #6707 [1], which deals with the implementation of ReverseManyRelatedObjectsDescriptor.__set__. Specifically, the problem is that the current implentation takes a very efficient "clear everything and add all the keys back in" approach to managing these

Re: Model proxy instance does not equal the respective model instance

Speaking on a semantic level, a "proxy" is a stand-in acting on behalf of (or in place of) another entity. There is an implied near- equivalence, but inherent in the idea of a proxy is that it is *not* the same as the original. As in the case of assigning a proxy to vote for you in corporate

Re: #6375 -- Class Based Views: Opinions on commit plan

I got my first real taste of the new API today by thoroughly proofing the docs for class-based views. I just wanted to say that there's some great stuff in there, and I give a big thanks to everyone who contributed! I'm really looking forward to using the new class-based views ASAP. Thanks!

Re: #6375 -- Class Based Views: Opinions on commit plan

> What do you call this. I don't see how any software developer could > consider constructive criticism as anything other than helping out. You've posted three messages in this thread, but none of them seem "constructive" to me. You've pointed out areas of disagreement and used inflammatory

Re: It is real to add ticket #8054 to 1.3 milestone?

Hi alekam, This is certainly the kind of ticket that we want to deal with in 1.3 since it's been around so long and deferred a couple times. Starting the discussion here is definitely the right way to make it happen. That said, at the very least it needs a thorough code review, a full set of

Re: Congratulations!

If you glance at the revision log for the committers page in the docs, there are actually a couple more ;-) http://code.djangoproject.com/log/django/trunk/docs/internals/committers.txt On Oct 8, 6:15 pm, Łukasz Rekucki wrote: > I just noticed we have 2 new Core Developers:

Contributing "How To"

There has been repeated talk of putting together resources for new contributors in a way that's more accessible and to-the-point than the current contributing docs. Most recently Russell mentioned it in this thread:

Re: Site app should be able to make absolute URLs #10944

I added some feedback on the ticket. Looks like a good start! - Gabriel On Oct 4, 2:12 pm, Laurent Luce wrote: > Hello, > > I added a patch to this ticket http://code.djangoproject.com/ > ticket/10944">#10944 > > - add method get_url to Site model to return an

Re: Sites Framework: RequestSite and get_current

possible. Thanks! - Gabriel On Oct 1, 4:12 am, Luke Plant <l.plant...@cantab.net> wrote: > On Thu, 2010-09-30 at 23:48 -0700, Gabriel Hurley wrote: > > I went to triage a few tickets tonight, and noticed that #8960, > > #10235, #10608 and #13814 have all arrived at

Re: Sites Framework: RequestSite and get_current

om request: > request.site with default implementation to LazySite, with default > implementation of Site.objects.get_current() if sites_installed() or > RequestSite(request). > > That implementation would be overriden with middleware > > What do you think? > > > > >

Re: How to "lobby" for a ticket to be in 1.3?

Sorry, that was phrased badly on my part. I meant to imply that if someone else wrote a patch, he could help by reviewing it... - Gabriel On Oct 1, 11:47 am, Jeremy Dunck <jdu...@gmail.com> wrote: > On Fri, Oct 1, 2010 at 1:41 PM, Gabriel Hurley <gab...@gmai

Re: How to "lobby" for a ticket to be in 1.3?

Well, looking at those two tickets, #7028 is currently related to the debate happening on this list ("rethinking raw_id_fields"), so the best thing to do for that ticket is to actively participate in that discussion. For #6903 the ticket is in DDN, which means this is a perfect opportunity for

Re: Sites Framework: RequestSite and get_current

Site/RequestSite as well. - Gabriel On Sep 30, 11:48 pm, Gabriel Hurley <gab...@gmail.com> wrote: > I went to triage a few tickets tonight, and noticed that #8960, > #10235, #10608 and #13814 have all arrived at essentially the same > conclusion: there needs to be a single idiom

Sites Framework: RequestSite and get_current

I went to triage a few tickets tonight, and noticed that #8960, #10235, #10608 and #13814 have all arrived at essentially the same conclusion: there needs to be a single idiomatic way to get either the current Site object if contrib.sites is installed, or a RequestSite object if not. All four

Re: #13870: Correctly handling database isolation (in PostgreSQL)

I ran into this issue with daemons/scheduled jobs and "idle in transaction" in Django quite a while ago. I have a nice writeup of the problem and solution on this StackOverflow question if anybody's interested:

Re: python 3.x

The RHEL/Python 2.4 question was addressed at length not more than a month ago: http://groups.google.com/group/django-developers/browse_frm/thread/b7390024b28a694d/f72c272152e968d7 Russell's reply there spells it out as clearly as anyone will be able to right now... All the best, - Gabriel

Re: Proposal: Revised form rendering

Thanks for the thoughtful reply, Russ! Just a couple quick points: > As noted in my reply to Preston, this should easily possibly using > chrome; I'm not sure I see why you disagree. The new options may be > funcitonal, but from my reading of the HTML5 spec, they're functional > in terms of UX,

Re: Proposal: Revised form rendering

ghtmare. So, whether these become filters, or arguments to the {% form %} tag, I really can't support them being implicit in the form tag that gets loaded. No magic here, please! Those concerns aside, I really like the rest of the proposal. This seems like a great step forward, and the ideas abou

Re: Suggestion of exception Http301 add as new feature

Http301 doesn't seem entirely correct to me, however I have found use for an Http302/HttpLoginRedirect exception that can be raised from anywhere to handle unauthorized users. If your authorization process is handled somewhere other than directly in a view or decorator (like in a manager that

Re: django.contrib.admin.ModelAdmin.formfield_for_manytomanyfield

You're right that formfield_for_manytomany probably ought to be better documented. If you aren't sure how to write a patch for the docs, the best thing to do is to open a ticket for the issue in Trac. That way it will be logged and someone else can look at it, write a patch, and eventually get it

Re: Proposal: {% include_partial %} template tag

Extending the include tag seems like a fantastic idea! I end up writing the {% with %}{% include %} combo all the time for my reusable template snippets. However, I feel like selectively clearing the context inside a template tag is asking for trouble and/or confusion. It also sounds like it goes

Re: Proposal: modular django configuration

For the record, the "from settings_default..." method is exactly how my team's largest projects are deployed. It works just fine for us! Even more fun (though bordering on too tricky) is converting INSTALLED_APPS to a set instead of a list so you can add *or* subtract items. This whole argument

Re: Ticket #10284

Hi, J. Alheid, Don't be too afraid to get started. From looking at the history on that ticket (as well as the current codebase), my guess is that Jacob's concern is that there's no mechanism in place for handling what happens to those objects if commit=False. The current patch tells us what *not*

Re: Project-wide cache prefix (low-level API)

Personally, I solved this by writing a wrapper around django.utils.cache that can be dropped in transparently. It was a really simple matter to have it take a cache prefix (in my case from settings.py) and pass that into the original functions. It's a pretty easy fix if the core team agrees that

Re: Feature idea

I like the idea of boxing up the autodiscover code into a publicly accessible utility class... it's a problem many people solve for themselves (myself included) but even moreso it would go well with the new startup.py proposal that's in the works. Once it's easy to have things run once at

Re: Upgrading Trac

Is it worth upgrading to the 0.11.X branch with Trac 0.12 scheduled to be out the door within a couple weeks? On the one hand, a brand new Trac release would be more likely to contain bugs than a bugfix branch that's now on it's 7th revision. The configurable workflows and per-user permissions

Re: Trac workflow assistance (commiter feedback needed)

I'd also be interested in working on this, as long as I'm not alone on it. Have you and/or Alex set up any kind of mailing list for it? Do you plan to use git's issue tracker or something else? What's the process plan for getting development kick-started on it? - Gabriel On Apr 30, 11:22 am,

Re: Trac workflow assistance (commiter feedback needed)

On Apr 30, 8:02 am, Jeremy Dunck wrote: > I haven't heard one proposed.  I'll take a look at RedMine and/or > steal ideas from launchpad -- but writing a new tracker isn't the > problem I'm trying to solve. FWIW, I currently use (and administer) Redmine for my company. I'd

Re: Django unit test coverage

One of the GSOC projects that was accepted is about updating and improving Django's test suite. The guy doing it has expressed interest in using coverage.py to help with the project (whether as a long-term part of django or just for the GSOC project), so there'll probably be more concrete

Re: Trac workflow assistance (commiter feedback needed)

I'm in a similar boat to Russell... LaunchPad's UI always seemed like a complete disaster to me... However, in reading through LaunchPad's FAQ to give it a fair chance, I saw a couple of other features that Trac doesn't have to add to the list: * Out-of-the-box OpenID support * "Bug Expiry" to

Re: Trac workflow assistance (commiter feedback needed)

I've been dancing around this idea for a while. I know it's not a new thought, and Alex Gaynor and Justin Lilly even started work on "piano man" [1]... I'd be curious to know what the state of that project is and if a few more devs working on it might be able to bring it to a place where it'd be

Re: Process discussion: reboot

On Apr 22, 1:21 pm, Adam Nelson wrote: > 2. Assign all of these tickets to 1.3 and nothing else: > > http://code.djangoproject.com/query?status=new=assigned... A, only 900 tickets to work through for 1.3? Don't go too easy on the core team! ;-) All the best, - Gabriel

Re: managing javascript and css resources

I like the idea of having these "bundles" or "stacks" for media. Just thinking out loud here, if there were a compression engine in play that could do concatenation as well as minification you could have a useful syntax for ordered combinations of scripts similar to how ModelAdmin's fieldsets work

Re: Process discussion: reboot

I just built something in a similar vein as this for my team's internal use. Amusingly, I used Django's inspectdb feature to directly interface with Redmine's database and provide a separate front-end. The data feeds into a javascript graphing library. The ability to visualize languishing issues,

Re: Process discussion: reboot

tch was rewritten in order to pass > >> the tests. > >> Another bit on proper documentation, some notes on quality, where to get > >> help, what types of issues need discussion on this list would be great and > >> I'm sure there's more that could be included with thi

Re: Process discussion: reboot

That's awesome. I'll definitely add to that when I have some time tonight. On Apr 20, 2:49 pm, Robert Coup wrote: > On Wed, Apr 21, 2010 at 9:12 AM, Jacob Kaplan-Moss wrote: > > I like this a lot. Especially the "your next steps" part - it

Re: Wherein Benjamin Franklin answers questions pertaining to the Django development process

Brilliant! Absolutely brilliant! - Gabriel On Apr 19, 4:23 pm, Bitrot McGee wrote: > Q: When will Django finally have every feature I want? > A: "Ambition has its disappointments to sour us, but never the good > fortune to satisfy us." > > Q: What the fuck is taking so

Re: Low-Hanging Fruit

I just want to second this suggestion from Russell: On Apr 19, 8:11 am, Russell Keith-Magee wrote: > Lastly, pick anything to do with documentation. This isn't a coding > problem, obviously, but writing up a documentation patch to clarify > some issue will help you get

Re: Process discussion: reboot

Before I even say anything: I think the core team does a great job, they're as fair as humanly possible in their decisions, and Django's stability is amazing. My disclaimer out of the way, I'd like to share my own experience of being a new contributor just to add another perspective. I only

Re: GSoC Proposal: Web Unifying Markup (templating) Language, or WUML

To be honest, my biggest question is "is this really about Django?" It seems like this proposal could have gone to anybody, or it could be a standalone app. I also would like to know if you have examples of other successful implementations of such a system that incorporate HTML, CSS, *and* JS

Re: Application to update the Test Suite

Maybe it's an overly simplistic question, but: what makes the tests slow currently? It's not simply the volume of them. It's more than possible for Python to race through hundreds of tests per second under the right conditions. Some of Django's test modules obviously zip along, but others seem to

Re: High Level Discussion about the Future of Django

If you haven't already, take a read through the "internals" section of the docs. It covers a number of the questions you've asked about deprecation, what can be changed in minor (1.x) releases, etc. http://docs.djangoproject.com/en/dev/internals/ They were definitely interesting for me. Being a

  1   2   >