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

Hello, I'm not sure if the consensus so far is either "Meh" or "Let's give it a try", or if there's even a consensus. I'm still keen on the idea but I don't want to insist too much if it doesn't gather enough support, so I'll re-submit it here one last time. The latest proposal is to introduce a

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

On Mon, Mar 28, 2011 at 2:12 PM, Julien Phalip wrote: > Hello, > > I'm not sure if the consensus so far is either "Meh" or "Let's give it > a try", or if there's even a consensus. I'm still keen on the idea but > I don't want to insist too much if it doesn't gather enough

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

On Mon, Mar 28, 2011 at 2:28 PM, Russell Keith-Magee wrote: > On Mon, Mar 28, 2011 at 2:12 PM, Julien Phalip wrote: >> Hello, >> >> I'm not sure if the consensus so far is either "Meh" or "Let's give it >> a try", or if there's even a consensus. I'm

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

On Mon, Mar 28, 2011 at 2:31 AM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > On Mon, Mar 28, 2011 at 2:28 PM, Russell Keith-Magee > wrote: > > On Mon, Mar 28, 2011 at 2:12 PM, Julien Phalip > wrote: > >> Hello, > >> > >> I'm not sure if

Re: Trac components cleanup

On Mon, Mar 28, 2011 at 1:56 PM, Julien Phalip wrote: > Hi all, > > Now that 1.3 has been released (yay!), I'm reviving this thread to see > if we can make Trac a little more efficient on our way to 1.4. I'll > try to summarise what's been suggested so far in regard to

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

On 28 March 2011 17:28, Russell Keith-Magee wrote: > > * Uncategorized (default) > > * Feature request: for adding something new. > > * Bug report: for when an existing thing is broken or not behaving as > > expected. > > * Optimisation: for when an existing thing is not

Re: Trac components cleanup

On 03/28/2011 02:33 AM, Russell Keith-Magee wrote: > As with the other thread on Trac changes -- I agree this is worth > doing, but would like to hear some other core dev voices before making > any changes. These changes look to me like a gain in sanity on every front. +1 Carl -- You

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

On Mon, Mar 28, 2011 at 2:37 PM, Julien Phalip wrote: > On 28 March 2011 17:28, Russell Keith-Magee wrote: >> >> > * Uncategorized (default) >> > * Feature request: for adding something new. >> > * Bug report: for when an existing thing is broken or not

Re: Complains about FileField not deleting files in 1.3.

> One query for each model > containing one or more FileFields is enough to build a list of the files > that ought to exist, and any file not in that list can presumably be > removed. How can I sleep at night knowing that there is a maintenance cron job deleting files which can be "presumably be

Re: Trac components cleanup

On 28.03.2011, at 07:56, Julien Phalip wrote: > Now that 1.3 has been released (yay!), I'm reviving this thread to see > if we can make Trac a little more efficient on our way to 1.4. I'll > try to summarise what's been suggested so far in regard to improving > and clarifying the "Component"

Re: State of X-Sendfile support?

On 26/03/11 11:31, Graham Dumpleton wrote: > > Yes and no as nginx also has a X-Sendfile module, again possibly > optional (can't remember). I didn't know there was an X-Sendfile module for Nginx -- Search results for "nginx xsendfile" point me to X-Accel-Redirect. > In Apache/mod_wsgi when

Re: State of X-Sendfile support?

On Monday, March 28, 2011 9:15:45 PM UTC+11, Gustavo Narea wrote: > > On 26/03/11 11:31, Graham Dumpleton wrote: > > > > Yes and no as nginx also has a X-Sendfile module, again possibly > > optional (can't remember). > > I didn't know there was an X-Sendfile module for Nginx -- Search results >

Re: Proposal: Add current_app to request and pass it to template loaders.

By "current app," do you mean the app which contains the view to which the current URL is mapped? On Mon, Mar 28, 2011 at 12:39 AM, Tai Lee wrote: > Now that 1.3 is out, does any core dev have an opinion, feedback or > suggestions on this? > > I've solved my immediate

Re: Template Compilation

On Mar 27, 5:48 am, "G.Boutsioukis" wrote: > Hi, I'm thinking about submitting a proposal for template compilation > and I'm posting this as a request for more info. > > In particular, I remember this project being discussed last year and I > pretty much assumed that Alex

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

On Mon, Mar 28, 2011 at 2:28 AM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > On Mon, Mar 28, 2011 at 2:12 PM, Julien Phalip wrote: > > Hello, > > > > I'm not sure if the consensus so far is either "Meh" or "Let's give it > > a try", or if there's even a consensus.

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

On Mar 28, 10:49 pm, Karen Tracey wrote: > +1 on having a distinction between bug, feature, and optimization. > > I don't think both "Uncategorized" and "Other" are necessary. My reasoning for "Other" was that there might be things that are neither a bug, a feature or an

Re: Proposal: Add current_app to request and pass it to template loaders.

On Mar 28, 4:08 pm, Justin Holmes wrote: > By "current app," do you mean the app which contains the view to which > the current URL is mapped? I mean the "namespace" (instance name) for the requested URL or the "current_app" attribute of a context object which is

Re: Complains about FileField not deleting files in 1.3.

On Mon, Mar 28, 2011 at 5:16 PM, -RAX- wrote: >> One query for each model >> containing one or more FileFields is enough to build a list of the files >> that ought to exist, and any file not in that list can presumably be >> removed. > > How can I sleep at night knowing

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

On Mon, Mar 28, 2011 at 8:04 PM, Julien Phalip wrote: > On Mar 28, 10:49 pm, Karen Tracey wrote: >> +1 on having a distinction between bug, feature, and optimization. >> >> I don't think both "Uncategorized" and "Other" are necessary. > > My reasoning for

Re: Template Compilation

Hi all, I have also been working for about a year on such a template compiler, and recently published it on Github. You may be interested in this project: https://github.com/citylive/django-template-preprocessor ** Short summary of what already is possible, and what still needs to be done:

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

On 28/03/11 13:21, Russell Keith-Magee wrote: > Ok - so at this point, the option list is looking like: > > * Uncategorized > * Bug > * Release blocking Bug > * New Feature > * Optimization > > Yours, > Russ Magee %-) > I'm definitely +1 on this new field, and just sat down in order to

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

On Mon, Mar 28, 2011 at 10:32 PM, Luke Plant wrote: > On 28/03/11 13:21, Russell Keith-Magee wrote: > >> Ok - so at this point, the option list is looking like: >> >>  * Uncategorized >>  * Bug >>  * Release blocking Bug >>  * New Feature >>  * Optimization >> >> Yours, >>

Re: Trac components cleanup

On Mon, Mar 28, 2011 at 12:56 AM, Julien Phalip wrote: > Now that 1.3 has been released (yay!), I'm reviving this thread to see > if we can make Trac a little more efficient on our way to 1.4. I'll > try to summarise what's been suggested so far in regard to improving > and

Re: Complains about FileField not deleting files in 1.3.

On Mon, Mar 28, 2011 at 4:16 AM, -RAX- wrote: > Said so I will start implementing such a maintenance job, and I am > willing to share it so maybe we could include it in a future release > of django. Sounds good -- I look forward to seeing your code! Jacob -- You

Re: State of X-Sendfile support?

On Sat, Mar 26, 2011 at 8:45 AM, Waldemar Kornewald wrote: > That's pretty much exactly what django-filetransfers tries to do on > the download side: > http://www.allbuttonspressed.com/projects/django-filetransfers > Hotever it's not only for X-Sendfile, but also for any

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

On 28/03/11 15:50, Russell Keith-Magee wrote: > However, I accept your point about splitting bug into two categories. > Making it two different flags was a suggestion for expediency of > implementation, but I can see how it will complicate your life with > reports. So I suppose we'll just have to

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

On Mon. 2011-03-28 at 03:07 AM EDT, Russell Keith-Magee wrote: > One > possibility: have two 'bug' options -- "Bug" and "Release-blocking > bug". Easy to filter on, relatively easy to understand, and easy to > correct if it gets mistriaged. Apache HTTP Server uses a

Re: Template Compilation

- preprocess inheritance. (one important incompatibility: {% extend "..." %} should only get a string as parameter, not a variable! But honestly, I really don't know why someone would do that. For the record - we do! We don't have a core site base template. Each client on our system gets

Re: Template Compilation

On Mon, Mar 28, 2011 at 11:04 AM, Dan Fairs wrote: > We don't have a core site base template. Each client on our system gets > their own, as IA/branding etc. varies considerably (and indeed includes > chunks of markup that the client supplies directly). ... and

Re: State of X-Sendfile support?

On Mon, Mar 28, 2011 at 5:05 PM, Jacob Kaplan-Moss wrote: > On Sat, Mar 26, 2011 at 8:45 AM, Waldemar Kornewald > wrote: >> That's pretty much exactly what django-filetransfers tries to do on >> the download side: >>

Proposal: switch to HTML5 for bundled templates

Hi all, I'd like to put forward the proposal that we switch to HTML5 for all Django supplied templates in Django 1.4 (apart from some of the GIS templates which apparently require XHTML to work under IE). I'm quite prepared for this to get shot down in flames, but I think it is at the point where

Re: State of X-Sendfile support?

On Mon, Mar 28, 2011 at 11:22 AM, Waldemar Kornewald wrote: > I do agree that it's too complicated (esp., the forms) and I plan to > improve django-filetransfers in this regard. The biggest complexity > comes largely from file upload handling (which I understand isn't a >

Re: Proposal: switch to HTML5 for bundled templates

Hi Luke, On 03/28/2011 12:38 PM, Luke Plant wrote: > Overall, I think the advantages outweigh the disadvantages, that we have > to make the move sometime, and now is about the right time, or perhaps > slightly late. 100% agreed, for all the reasons you outlined. We've been using the HTML5

Re: Proposal: switch to HTML5 for bundled templates

I agree completely that we should move to HTML5. It seems like it will be even more important as more and more people use Smart Phones or Pads for surfing the net, and I believe all of these are supporting HTML5. I've started attending some HTML5 user group meetings, and I'm quite impressed with

Re: State of X-Sendfile support?

On Mar 28, 2011, at 9:40 AM, Jacob Kaplan-Moss wrote: > If I've got that wrong, you need to explain to me (and > anyone else) why uploads and downloads belong together in the same > patch and why a simple "just support X-Sendfile and friends" patch > can't possibly work. +1. It's entirely

Re: State of X-Sendfile support?

On Mon, Mar 28, 2011 at 6:40 PM, Jacob Kaplan-Moss wrote: > On Mon, Mar 28, 2011 at 11:22 AM, Waldemar Kornewald > wrote: >> I do agree that it's too complicated (esp., the forms) and I plan to >> improve django-filetransfers in this regard. The biggest

Re: State of X-Sendfile support?

On Mon, Mar 28, 2011 at 1:13 PM, Waldemar Kornewald wrote: > That's a good goal and as long as you only focus on file downloads > it's possible to reuse the middlewares setting. However, if you ever > want to provide an abstract file uploads API we're back to the same >

Django Lines of Code

Hi! I was just wondering if anyone knows the total number of lines of code of Django. Andrea -- 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

Re: Django Lines of Code

On Mon, Mar 28, 2011 at 3:29 PM, Andrea Zilio wrote: > I was just wondering if anyone knows the total number of lines of code > of Django. Hi Andrea -- This question's off-topic for this list. Django-dev is for discussion development of Django itself, and the length isn't

Re: Django Lines of Code

On Mon, Mar 28, 2011 at 3:36 PM, Jacob Kaplan-Moss wrote: ... > PS: 66,045 lines of code plus 51,174 lines of tests. Yes, but how many lines of docs? :-P -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this

Re: Trac components cleanup

On Mar 29, 2:01 am, Jacob Kaplan-Moss wrote: > On Mon, Mar 28, 2011 at 12:56 AM, Julien Phalip wrote: > > Now that 1.3 has been released (yay!), I'm reviving this thread to see > > if we can make Trac a little more efficient on our way to 1.4. I'll > > try

Re: Trac components cleanup

On Mon, Mar 28, 2011 at 4:08 PM, Julien Phalip wrote: > I wouldn't mind trying but I don't have much experience administering > Trac and I wouldn't want to make a mess. Earlier in this thread > Gabriel has offered to help as he's got the Trac skillz. > > Gabriel, are you

Proposal: remove compatibility for old signing functions

Proposal: remove compatibility fallbacks for short-lifetime signed data (shortening the deprecation process). = Explanation = In 1.3, various bits of code were updated to use a better system for signing using the SECRET_KEY. However, for compatibility with existing data, the old methods were

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: Proposal: remove compatibility for old signing functions

On Mon, Mar 28, 2011 at 4:19 PM, Luke Plant wrote: > Proposal: remove compatibility fallbacks for short-lifetime signed data > (shortening the deprecation process). Sounds perfectly fine to me. Skipping versions is generally a dicey idea anyway, so recommending a brief

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

I agree with the others. This is very much the correct step going forward. These fallback methods have worried me, and definitely weaken the security of the improvements. One idea I had been kicking around was some way to tell Django what version of these things to expect, and disable the

Re: Trac components cleanup

On Mar 29, 8:58 am, Gabriel Hurley wrote: > I can work on it late tonight (about 6-8 hours from now) if no one else gets > to it. > > All the best, > >     - Gabriel Excellent, thank you Gabriel! There's no rush -- whenever it suits you. Let me know if I can help in any way.

Re: Proposal: switch to HTML5 for bundled templates

+1. All major browsers now support html5 and by the time django 1.4 will be released we will be right on time though a bit late. In response to Gabriel, in my opinion, legacy problems should not be addressed by not moving forward, but they can be resolved by either 1. updating or 2. staying on a

Re: Proposal: switch to HTML5 for bundled templates

+1 No harm, as it breaks nothing currently using the templates. Sets a great message that Django moves forward. I like it. On Mon, Mar 28, 2011 at 12:38 PM, Luke Plant wrote: > Hi all, > > I'd like to put forward the proposal that we switch to HTML5 for all > Django

Re: Proposal: switch to HTML5 for bundled templates

On Tue, Mar 29, 2011 at 6:08 AM, Wim Feijen wrote: > +1. All major browsers now support html5 and by the time django 1.4 > will be released we will be right on time though a bit late. Statements like "All modern browsers support it" misses the point. It isn't the *modern*

Re: Proposal: switch to HTML5 for bundled templates

On 29/03/11 03:10, Russell Keith-Magee wrote: > Of course, this depends a great deal on the details of exactly what is > to be done, and where. Luke's proposal says we should "use HTML5 > features at least as an option in places like the admin", but the > provided patch is a unilateral switch to

Re: Proposal: switch to HTML5 for bundled templates

On Tue, Mar 29, 2011 at 10:26 AM, Luke Plant wrote: > On 29/03/11 03:10, Russell Keith-Magee wrote: >> Of course, this depends a great deal on the details of exactly what is >> to be done, and where. Luke's proposal says we should "use HTML5 >> features at least as an

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: Proposal: switch to HTML5 for bundled templates

Anyone interested in reading about html5 can find a lot of great information at http://diveintohtml5.org/. Some of the highlights: 1. a change to the doctype of the admin from http://www.w3.org/TR/xhtml1/DTD/xhtml1- strict.dtd"> to should still keep ie6 in Almost Standards Mode [1] 2. Browsers

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: Complains about FileField not deleting files in 1.3.

I think, cron jobs is an overhead in many simple cases where old behaviour was useful and more simpler. Why you don't want include DeletingFileField[1] in django? [1] https://gist.github.com/889692 On Mon, Mar 28, 2011 at 9:07 PM, Jacob Kaplan-Moss wrote: > On Mon, Mar 28,

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