On Mar 10, 6:55 pm, Andrew Godwin wrote:
> Hi all,
>
> I'm posting this here, not as a ticket, as I'm not entirely sure it's
> Django's problem, and so would like some input*.
>
> [Base]DatabaseCreation has a method sql_indexes_for_field, which,
> handily, returns the SQL indexes for a field. Less
On Thu, Apr 22, 2010 at 4:36 PM, Adam Nelson wrote:
> I guess I'll jump in and start triaging. What about a ticket like
> this:
>
> http://code.djangoproject.com/ticket/2284
>
> Super-ambiguous. There are dozens of tickets like this that are
> frozen in time with no way for anybody to know what'
I guess I'll jump in and start triaging. What about a ticket like
this:
http://code.djangoproject.com/ticket/2284
Super-ambiguous. There are dozens of tickets like this that are
frozen in time with no way for anybody to know what's going on. Maybe
there just needs to be a better way to handle
On Thu, Apr 22, 2010 at 3:26 PM, Gabriel Hurley wrote:
> 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&status=assigned&status...
>
> A, only 900 tickets to work through for 1.3? Don't go
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&status=assigned&status...
A, only 900 tickets to work through for 1.3? Don't go too easy on
the core team! ;-)
All the best,
- Gabriel
--
After reading through this entire thread it seems that there are a few
points to be consolidated:
1. DVCS concerns should be pushed to 1.4+ and in the meantime, mirrors
are fine.
2. The management of the current Trac system has organizational issues
- i.e. many people don't know who committers are
>Nothing I've seen so far solves, or even addresses the original need for
>_not_ sourcing the same script numerous times (thanks to widgets with
>their own media)
The widget and admin media system needs to be re-evaluated IMO
none of these solutions are going to address the flaws you are
refer
The django-compress looks a bit better as it has the option to do the
versioning (based on a file hash), compression, and concatenization
with a management command.
Django_compressor does this all on page load, which is not production
worthy IMO.
Generating an MD5 hash on page load is un-needed ov
Yeah, I'm still working through my growing list of projects:
https://www.google.com/bookmarks/l#!threadID=G6K-d-kjbHKA%2FBDSEyZAoQ09_aj4Il
I'm trying to examine each one in terms of features, as well as checking
the source to see how they are working.
Nothing I've seen so far solves, or even addre
Am 22.04.2010 um 20:28 schrieb Ned Batchelder:
FWIW, I just started using django-compress (http://code.google.com/p/django-compress/
) which works precisely this way. It has pluggable compressors,
control over the versioning of the combined files, and so on.
Also worth noting is django_com
FWIW, I just started using django-compress
(http://code.google.com/p/django-compress/) which works precisely this
way. It has pluggable compressors, control over the versioning of the
combined files, and so on.
--Ned.
Gabriel Hurley wrote:
I like the idea of having these "bundles" or "stack
reverse('special', args=[r'+\$*'])
> '/special_chars/+%5C$*/'
>
> It would have to output:
>
> '/special_chars/%2B%5C%24%2A/'
Hi,
I think the current test case is broken. All args/kwargs should
be quoted.
--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guet
12 matches
Mail list logo
