BTW, generally I like this idea... :)
On Mon, Dec 7, 2009 at 10:23 PM, Rick Yazwinski
wrote:
> I think that this may be too simplified:
> protocol = getattr(settings, "PROTOCOL", "http")
> domain = Site.objects.get_current().domain
> port = getattr(settings, "PORT", "")
>
> M
I think that this may be too simplified:
protocol = getattr(settings, "PROTOCOL", "http")
domain = Site.objects.get_current().domain
port = getattr(settings, "PORT", "")
Many sites put load balancers and https hardward acceleration in front
of their web interfaces. This wo
On Tue, Dec 8, 2009 at 11:11 AM, Tobias McNulty wrote:
> On Mon, Dec 7, 2009 at 6:31 PM, Russell Keith-Magee
> wrote:
>> I was thinking more of having one person at the sprint to take the
>> role of integrator - that is, the patches still go up on trac, but one
>> trusted person at the sprint tak
On Mon, Dec 7, 2009 at 6:31 PM, Russell Keith-Magee
wrote:
> I was thinking more of having one person at the sprint to take the
> role of integrator - that is, the patches still go up on trac, but one
> trusted person at the sprint takes the role of lieutenant for the
> sprint, and selects patches
OK, here is what I have gathered about the databases listed under
DATABASE_ENGINE [4].
Postgresql 8: Supports all three, +/-Inf and NaN [0]
MySQL: No support for either NaN or Inf [1]
sqlite3: No support for either NaN or Inf [2]
Oracle: Supports all three [3]
So, we have a 50/50 split. What do
On Tue, Dec 8, 2009 at 7:11 AM, Jeremy Dunck wrote:
>
> On Dec 7, 2009, at 5:02 PM, Russell Keith-Magee
> wrote:
>
>> Looking at new ideas to try - if someone trusted at the sprint (such
>> as yourself) were to take the role of developing a merge-ready git
>> branch, we (the committers) could use
On Dec 7, 2009, at 5:02 PM, Russell Keith-Magee
wrote:
> Looking at new ideas to try - if someone trusted at the sprint (such
> as yourself) were to take the role of developing a merge-ready git
> branch, we (the committers) could use that branch to feed into trunk.
> This hasn't been done
On Tue, Dec 8, 2009 at 6:57 AM, Johannes Dollinger
wrote:
> Ping.
>
> Since it's a non-trivial patch and there has been (almost) no
> feedback, is it save to assume that #7539 is not in scope for 1.2 ?
At this point, I'd have to say yes. We've still got a lot of items on
the high priority list, #
On Tue, Dec 8, 2009 at 5:46 AM, Jeremy Dunck wrote:
> Hey all,
> I was wondering if I could do anything to streamline applying
> sprint-created patches.
>
> Obviously, I can do triaging and provide feedback on patches. Can
> I be blessed to say "Ready for checkin"?
>
> What else can I do? I
Ping.
Since it's a non-trivial patch and there has been (almost) no
feedback, is it save to assume that #7539 is not in scope for 1.2 ?
Am 07.11.2009 um 01:31 schrieb Johannes Dollinger:
>
> There's a new patch on the ticket[1], based on Michael Glassford's
> work, that solves a few remaining
On Tue, Dec 8, 2009 at 5:59 AM, Jacob Kaplan-Moss wrote:
> Hi folks --
>
> According to our timeline, we're at (a bit past, actually) the point
> where we need to take a quick look at progress towards 1.2 and decide
> whether the current timeline still makes sense.
>
> Right now, we've completed 4
This made it to the 1.2 feature list:
http://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl
If we want this in 1.2, it could be as simple as merging the get_url /
get_url_path methods in to the base Model class, rolling a few unit
tests and writing some documentation. It feels like we should
On Tue, Dec 8, 2009 at 1:16 AM, Jacob Kaplan-Moss wrote:
> On Mon, Dec 7, 2009 at 11:05 AM, Adrian Holovaty wrote:
>> Unless Jacob feels strongly otherwise, let's go with class-based.
>
> Nope, I don't feel strongly at all. I think I agree that I've a slight
> preference for the explicitness of n
On Mon, Dec 7, 2009 at 4:13 PM, Jeremy Dunck wrote:
> Perhaps I missed the gripping conclusion, but wasn't there some
> outstanding work to be done on multi-db's interaction with admin?
The conclusion was that we could (and should, eventually) make it
easier (perhaps a `using` option on ModelAdmi
On Mon, Dec 7, 2009 at 5:13 PM, Jeremy Dunck wrote:
> On Mon, Dec 7, 2009 at 4:03 PM, Alex Gaynor wrote:
>
>> I'm very confident that multi-db will be ready for merge by then,
>> Justin and I (ok mostly Justin) have been working on the GIS stuff,
>> which is the last blocker.
>
> Perhaps I m
On Mon, Dec 7, 2009 at 4:03 PM, Alex Gaynor wrote:
> I'm very confident that multi-db will be ready for merge by then,
> Justin and I (ok mostly Justin) have been working on the GIS stuff,
> which is the last blocker.
Perhaps I missed the gripping conclusion, but wasn't there some
outstandin
On Mon, Dec 7, 2009 at 4:59 PM, Jacob Kaplan-Moss wrote:
> Hi folks --
>
> According to our timeline, we're at (a bit past, actually) the point
> where we need to take a quick look at progress towards 1.2 and decide
> whether the current timeline still makes sense.
>
> Right now, we've completed 4
On Mon, Dec 7, 2009 at 3:46 PM, Jeremy Dunck wrote:
> Obviously, I can do triaging and provide feedback on patches. Can
> I be blessed to say "Ready for checkin"?
Please - that'd really help me.
Jacob
--
You received this message because you are subscribed to the Google Groups
"Django deve
Hi folks --
According to our timeline, we're at (a bit past, actually) the point
where we need to take a quick look at progress towards 1.2 and decide
whether the current timeline still makes sense.
Right now, we've completed 4.5 features on the 1.2 priority list:
* Comment admin actions (Co
On Mon, Dec 7, 2009 at 4:46 PM, Jeremy Dunck wrote:
> Hey all,
> I was wondering if I could do anything to streamline applying
> sprint-created patches.
>
> Obviously, I can do triaging and provide feedback on patches. Can
> I be blessed to say "Ready for checkin"?
>
> What else can I do? I
Hey all,
I was wondering if I could do anything to streamline applying
sprint-created patches.
Obviously, I can do triaging and provide feedback on patches. Can
I be blessed to say "Ready for checkin"?
What else can I do? I think getting patches which are actually
ready to be committed q
On Mon, Dec 7, 2009 at 11:05 AM, Adrian Holovaty wrote:
> My preference is (slightly) for class-based, because it's (slightly)
> less magic. I think we should try to avoid requiring people to
> remember what to name things.
I like this as well, albeit for a slightly different reason: asking
you t
On Mon, Dec 7, 2009 at 11:05 AM, Adrian Holovaty wrote:
> Unless Jacob feels strongly otherwise, let's go with class-based.
Nope, I don't feel strongly at all. I think I agree that I've a slight
preference for the explicitness of naming the class "out loud," so
let's do that.
Jacob
--
You rece
On Mon, Dec 7, 2009 at 6:17 AM, Russell Keith-Magee
wrote:
> So, I'd like to call for a quick BDFL judgement. Everyone else should
> feel free to weigh in with opinions if they have opinions,
> preferences, or especially compelling arguments either way.
My preference is (slightly) for class-based
On topic, I'm +0 on class-based approach.
There's actually one passage that reminded me of something that I
consider a small wart in a couple of places in Django:
Russell Keith-Magee wrote:
> Module-based configuration:
> ---
>
> * The aesthetic of user-configuration op
Just wanted to add that the decision need not go either way; one possible
solution would be to leave it up to the implementation and live with both
conventions in the core.
Sent from a mobile phone, please excuse any typos.
On Dec 7, 2009 7:17 AM, "Russell Keith-Magee"
wrote:
Hi all (and especi
I slightly prefer class-based configuration.
Karen
--
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, send email to
django-developers+un
On Mon, Dec 7, 2009 at 3:05 AM, Tobias McNulty wrote:
> On Sat, Dec 5, 2009 at 10:24 PM, Russell Keith-Magee
> wrote:
>> However, I'm also willing to admit that personal preference is a
>> factor here. We may just need to push this up for a BDFL judgement. I
>> would certainly prefer module level
Hi all (and especially Jacob),
So - this is a call for any interested parties to express their
opinions, followed (hopefully quickly) by a BDFL judgement.
For those that haven't been following the the django-dev discussion
around ticket #4604: session-based messages are nearing trunk ready
status
29 matches
Mail list logo
