On 12 jun, 21:37, "Leo Soto M." <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 12, 2008 at 8:35 PM, Ramiro Morales <[EMAIL PROTECTED]> wrote:
> [...]
>
> > Since then I've opened ticket [2]#7420 with a patch
>
> I see that part of the patch deals with the fact that the underlying
> adapter prefer to
Excellent.
This could be added to google code? Is more easy run on trunk thta
doing the patching dance...
I test this shortly. I hope we could do this and prove that is doable
to all the *nix db guys ;)
--~--~-~--~~~---~--~~
You received this message because you
On Mon, Jun 16, 2008 at 5:10 PM, Ramiro Morales <[EMAIL PROTECTED]> wrote:
> /me greps over the cx_Oracle 4.3.3 and 4.4 source trees.
>
> It's me or cx_Oracle doesn't have an autocommit symbol at all?. In
> fact, it hasn't
> a set_isolation_level one either.
It does as of version 4.3.2. I know
> To solve it I proposed[1] another strategy: delegate type conversion
> to the backend. Otherwise, I think we will end with too many backend
> flags.
+1
I maintain the external Firebird backend and I would also prefer this
solution.
Ivan Illarionov
Ian,
On Thu, Jun 12, 2008 at 10:49 PM, Ian Kelly <[EMAIL PROTECTED]> wrote:
>> connection.autocommit is an attribute and not a method (didn't find a way to
>> cleanly monkeypatch this).
>
> It's also an attribute in cx_Oracle. I'll have to take a look at it
> some time and figure out why it's
El lun, 16-06-2008 a las 10:00 -0700, [EMAIL PROTECTED] escribió:
> I really like the roadmap, but I'm wondering where the docs-
> refactoring work comes in?
It in "Maybe" features, second from the bottom on
http://code.djangoproject.com/wiki/VersionOneFeatures
--
http://www.marcfargas.com --
I really like the roadmap, but I'm wondering where the docs-
refactoring work comes in?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to
On Mon, Jun 16, 2008 at 10:22 AM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Has anyone else noticed that development progress seems to have
> exploded since this thread was created? In the weeks/months after the
> qs-rf merge, several days would go by when there wasn't a single
> change
Has anyone else noticed that development progress seems to have
exploded since this thread was created? In the weeks/months after the
qs-rf merge, several days would go by when there wasn't a single
change committed, but suddenly there have been like 10 per day in the
last few days.
On Mon, Jun 16, 2008 at 3:46 PM, Marc Fargas <[EMAIL PROTECTED]> wrote:
> El lun, 16-06-2008 a las 11:28 +0800, Russell Keith-Magee escribió:
>> A bug/feature keyword won't
>> give you anywhere as much attention, but it will help us filter out
>> features from the list of work we need to focus
El lun, 16-06-2008 a las 11:28 +0800, Russell Keith-Magee escribió:
> A bug/feature keyword won't
> give you anywhere as much attention, but it will help us filter out
> features from the list of work we need to focus on.
I took the other way around, I'm adding the keyword "post10" for tickets
On Sun, Jun 15, 2008 at 9:16 PM, Marc Fargas <[EMAIL PROTECTED]> wrote:
> El dom, 15-06-2008 a las 14:11 +0800, Russell Keith-Magee escribió:
>> Adding a 'bug' or 'feature' as a keyword on the tickets is one way to track
>> this.
>
> I thought about that, but the same that happened with
Hey all,
For those of us attending the EuroPython 2008 conference or wishing to
join online through IRC: W'll be holding a sprint during the
EuroPython sprint days to get newforms-admin merged into trunk asap
(see Jacob's roadmap that started this thread). If you want to help
out, please add
El dom, 15-06-2008 a las 14:11 +0800, Russell Keith-Magee escribió:
> Based purely upon the ticket titles, they certainly sound like good
> candidates.
Thanks, my criteria is now completely flawed! ;)
> You have been doing a lot of good triage work over the last few days
Thanks again :)
> have
On Sat, Jun 14, 2008 at 10:50 PM, Marc Fargas <[EMAIL PROTECTED]> wrote:
> Hi there,
>
> El mié, 11-06-2008 a las 21:03 -0500, Jacob Kaplan-Moss escribió:
> On my today's triaging session (64 unreviewed left now) I spotted a few
> bugs in Unreviewed of those kind that should be fixed before 1.0,
On Jun 12, 7:23 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> On Wed, Jun 11, 2008 at 9:13 PM, Russell Keith-Magee
> On comments
> ---
>
> ``django.contrib.comments`` is a bit of special case here: ideally, Django 1.0
> will ship with *no* core use of oldforms. However, refactoring
El sáb, 14-06-2008 a las 13:28 -0700, Charlie escribió:
> I'm curious if there are any plans to support simple urls for "RESTful
> resources" in Django, especially before the 1.0 release.
It's not on the roadmap to 1.0 so it won't be there, there's a project
around that see this list archives on
I'm curious if there are any plans to support simple urls for "RESTful
resources" in Django, especially before the 1.0 release.
See discussion here:
http://lethain.com/entry/2008/jun/13/a-django-anti-pattern-rolling-your-own-rest/
--~--~-~--~~~---~--~~
You
Hi there,
El mié, 11-06-2008 a las 21:03 -0500, Jacob Kaplan-Moss escribió:
> * Two beta releases.
>
> All "maybe" features must be completed by the first beta; after that,
> Django will enter feature freeze for about a month while we kill bugs.
>
> * At least one -- and hopefully only one
> To solve it I proposed[1] another strategy: delegate type conversion to the
> backend.
+1
I maintain the external django-mssql backend, and I would HUGELY
prefer to get "real Python types" instead of to-string types for
things like dates/times/decimal/etc.
(Converting everything to strings
On Thu, Jun 12, 2008 at 6:35 PM, Ramiro Morales <[EMAIL PROTECTED]> wrote:
> Since then I've opened ticket [2]#7420 with a patch that would reduce the list
> of things needed to patch in Django to just *one item: Taking in account the
> fact that in pyodbc seems to be the only DB-API2 adapter
On Thu, Jun 12, 2008 at 8:35 PM, Ramiro Morales <[EMAIL PROTECTED]> wrote:
>
> Jack Moffitt, mamcx (and everyone interested),
>
> I've been working in my free time for the last few days on updating the
> pyodbc-based MS SQL Server backend so it a) can be an external Django
> backend and b) to
Jack Moffitt, mamcx (and everyone interested),
I've been working in my free time for the last few days on updating the
pyodbc-based MS SQL Server backend so it a) can be an external Django
backend and b) to post qs-rf merge.
First I tried to participate by testing django-pyodbc and opening a
+1 on trac milestones. I think it's important that people start to see
what will be done when and what features will get pushed off to 1.0.
Milestones, at least for me as a growing developer, have always
provided that extra motivation as the progress meter approaches 100%.
Just seems more
As one of the guys that try to do the MS-Sql part:
http://code.djangoproject.com/ticket/5062
I must say that I sell a internal semi-store with that code, integrate
later http://code.djangoproject.com/ticket/5246 and work fine.
But feel that the django people discourage the work at all. First,
Ville Säävuori wrote:
> The point of deadlines are that people tend to try to make them come
> true. If there is something that I've learned as a project manager
> during all the years that I've worked as one, it's that deadlines are
> important.
My main point was that the deadline should be
I'd like to bring up trac milestones again.
Currently Django has over 1000 active tickets. Some of them are
relevant to oldforms-admin, some are from pre-qsrf merge, some are
features for 1.1. But quite a few are small bugs that should be fixed
before 1.0.
Putting up milestones in trac would
Jacob, I feel your pain butty.
Do what you think is right, django has been brilliant so far.
The jump to version 1(lightspeed) has been a bit of a nightmare, but let's
all remember a pre django world.
I for one trust Jacob's judgement.
Just do it mate, there's good good people who want to
> So what's the point of hoping for September if it's not real?
The point of deadlines are that people tend to try to make them come
true. If there is something that I've learned as a project manager
during all the years that I've worked as one, it's that deadlines are
important.
Its not as
On Thu, Jun 12, 2008 at 11:10 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> And this is great of course. But having to develop externally away
> from the many eyes of the Django community is sort of an impairment.
> It's a lot easier to get traction on a project that is in the Django
> repo
On Thu, Jun 12, 2008 at 16:39, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
>
> On Thu, Jun 12, 2008 at 3:32 AM, Gábor Farkas <[EMAIL PROTECTED]> wrote:
>>
>>> 5. Model-level validation (#6845).
> [...]
>> and i thought it's in the plan to have this in 1.0.
>
> It is, assuming it gets done.
Honza Král
E-Mail: [EMAIL PROTECTED]
ICQ#: 107471613
Phone: +420 606 678585
On Thu, Jun 12, 2008 at 10:32, Gábor Farkas <[EMAIL PROTECTED]> wrote:
>
> On Thu, Jun 12, 2008 at 4:03 AM, Jacob Kaplan-Moss
> <[EMAIL PROTECTED]> wrote:
>>
>> "Maybe" features
>>
>>
> .
> .
> .
>>
>>
On Jun 12, 8:51 am, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 12, 2008 at 7:06 AM, Forest Bond <[EMAIL PROTECTED]> wrote:
> > I think that this is a must-have:
>
> > #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
>
> Then you'll be glad to know that it's #3 the list of "Must-have
>
> > The schedule looks good. I think you should be hardlined about the
> > dates and not as hardlined on what makes it in.
>
> That's the plan. Only the "blocker" features actually can delay the
> release, and I expect them to be done (sans bug fixes) by that alpha
> date.
What I meant was, if
On Jun 12, 4:43 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> On Thu, Jun 12, 2008 at 8:42 AM, Remco Wendt <[EMAIL PROTECTED]> wrote:
> > Will the API be frozen from the alpha release? Or is this a beta
> > release thing?
>
> I'm not sure... I think probably beta 1 should be the API
> > I have to ask why must Django prevent work in this regard?
>
> To be perfectly fair, it's not really "prevented". Django supports the
> use of database backends not defined in Django itself, so third-party
> development of backends is unimpaired.
And this is great of course. But having to
On Thu, Jun 12, 2008 at 8:42 AM, Remco Wendt <[EMAIL PROTECTED]> wrote:
> Will the API be frozen from the alpha release? Or is this a beta
> release thing?
I'm not sure... I think probably beta 1 should be the API freeze, but
it's possible that with all the new features due at that point we
On Thu, Jun 12, 2008 at 3:32 AM, Gábor Farkas <[EMAIL PROTECTED]> wrote:
>
>> 5. Model-level validation (#6845).
[...]
> and i thought it's in the plan to have this in 1.0.
It is, assuming it gets done. Last I check Honza was working on it,
and if he's still interested I expect he'd be able
On Thu, Jun 12, 2008 at 7:58 AM, Luke Plant <[EMAIL PROTECTED]> wrote:
> First, I think you meant #730
> Second, I think this needs to be a must have, or at least the current
> behaviour must be *documented*. See discussion on #749
Yup, I meant #730, and I think you're right that we should
On Thu, Jun 12, 2008 at 5:18 AM, Ivan Sagalaev
<[EMAIL PROTECTED]> wrote:
> Ouch... To paraphrase Joel Spolsky "If you have a hand-wavy feature
> called "1.0 release" and you schedule 3 months for it, you are doomed".
> Jacob, honestly, where this date has come from? It can as easily be
> August
On Wed, Jun 11, 2008 at 11:17 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I have to ask why must Django prevent work in this regard?
It's not so much about "preventing" work -- nobody here works *for*
me, and I can't really tell anybody what to do. It's more about
focusing priorities. So
+1 on getting a release out there as soon as humanly possible ;)
On Jun 12, 4:03 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> * An alpha release containing all must-have features, but likely not
> bug-free. We'll push hard to have all the must-haves done in time
> for ample testing.
Ville Säävuori wrote:
> Firstly, as Jacob said, the schedule is just a draft at this point.
> But I'm very much +1 on locking down spesific dates for any given
> milestone. It's vital to have firm schedule and dates for making it
> all happen in a relatively short period of time.
If this is
On Thursday 12 June 2008 03:03:21 Jacob Kaplan-Moss wrote:
> 11. Better support for controlling middleware ordering (#3591).
First, I think you meant #730
Second, I think this needs to be a must have, or at least the current
behaviour must be *documented*. See discussion on #749
Thanks,
On Thu, Jun 12, 2008 at 7:06 AM, Forest Bond <[EMAIL PROTECTED]> wrote:
> I think that this is a must-have:
>
> #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
Then you'll be glad to know that it's #3 the list of "Must-have
features" in Jacob's email, just a bit below the portion you quoted.
-Gul
On Jun 12, 12:46 pm, Ville Säävuori <[EMAIL PROTECTED]> wrote:
> And FWIW, I think the proposed roadmap is brilliant. Not too many
> features but still enough to make most of us very happy. Especially if
> we can get at least few of the maybes in.
Agreed. It is great to see a concrete plan
> Jacob, honestly, where this date has come from? It can as easily be
> August or October. You've outlined a good feature list and seem resolute
> to stick to it. But unless all those lieutenants would plan their
> features *in work hours*, you just can't know the date.
Firstly, as Jacob said,
Hi,
On Jun 11, 10:03 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> * Must-haves: features that, if not completed, are worth delaying the
> release. That is, if the work on this list is not completed by a
> release date, we'll push the date.
I think that this is a must-have:
#285
Wow, I'd say this is a pretty good schedule, Jacob.
> So we'd like to deal with that situation a bit specially. I've
> unfortunately not
> had a chance to ask Thejaswi (the student working on comments) or
> Jannis (his
> mentor) about this, so obviously they'll need to be OK with the idea.
Jacob Kaplan-Moss wrote:
> Django 1.0 will be released in early September.
Ouch... To paraphrase Joel Spolsky "If you have a hand-wavy feature
called "1.0 release" and you schedule 3 months for it, you are doomed".
Jacob, honestly, where this date has come from? It can as easily be
August or
Hi Jacob,
On Thu, Jun 12, 2008 at 5:03 AM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> 7. Land GeoDjango as ``django.contrib.gis``.
Not that I have any right to say anything ... but should this really
be a django contrib ? Isn't it more of an external application ?
Regards
Rajeev J
On Thu, Jun 12, 2008 at 4:03 AM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
>
> "Maybe" features
>
>
.
.
.
>
> 5. Model-level validation (#6845).
hi,
it always seems quite ugly, that you can create a model with invalid data,
and save it. so when you want to validate it's
On Wed, Jun 11, 2008 at 11:17 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I have to ask why must Django prevent work in this regard?
To be perfectly fair, it's not really "prevented". Django supports the
use of database backends not defined in Django itself, so third-party
development of
> This is a call for comments on the proposed Django 1.0 roadmap and schedule.
[snip]
> Must-have features
I love that this list is small and concentrated. This is exactly what
is needed in order to get a release out quickly and focus development
effort.
+1 from me.
> "Maybe" features
These
On Wed, Jun 11, 2008 at 11:29 PM, Russell Keith-Magee <
[EMAIL PROTECTED]> wrote:
>
> On Thu, Jun 12, 2008 at 10:54 AM, Jacob Kaplan-Moss
> <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, Jun 11, 2008 at 9:46 PM, Karen Tracey <[EMAIL PROTECTED]>
> wrote:
> >> One thing I don't see mentioned anywhere
That list seems perfect to me. I'll be around in San Francisco to
help on the sprint, so if #6095 isn't merged by then I can focus on
whatever needs to be done to get it to where it needs to be.
-Eric Florenzano
--~--~-~--~~~---~--~~
You received this message
On Wed, Jun 11, 2008 at 9:59 PM, George Vilches <[EMAIL PROTECTED]> wrote:
>> 8. Many-to-many intermediates (#6905).
>>
> Shouldn't that be #6095? http://code.djangoproject.com/ticket/6095
Yup; thanks.
Jacob
--~--~-~--~~~---~--~~
You received this message
On Wed, Jun 11, 2008 at 9:56 PM, Julien <[EMAIL PROTECTED]> wrote:
> In the must-have features, or at least in the maybes, I'd put the bugs
> introduced by, or not properly fixed by, the merge of the queryset-
> refactor branch. A list of related open tickets has been given in [1].
A better list
Just one fix to this list:
On Jun 11, 2008, at 10:03 PM, Jacob Kaplan-Moss wrote:
> 8. Many-to-many intermediates (#6905).
>
Shouldn't that be #6095? http://code.djangoproject.com/ticket/6095
George
--~--~-~--~~~---~--~~
You received this message because you
Seems like a very good roadmap, and it must clear a lot of concern and
uncertainty some people may have.
In the must-have features, or at least in the maybes, I'd put the bugs
introduced by, or not properly fixed by, the merge of the queryset-
refactor branch. A list of related open tickets has
On Wed, Jun 11, 2008 at 9:27 PM, Jeff Anderson <[EMAIL PROTECTED]> wrote:
> I'm curious: is there a reason that the milestone feature was disabled on
> the trac page?
> Would it be good/beneficial to put these "must-haves" in a 1.0 milestone,
> and (some of) the "No" features in a 1.1 milestone?
On Wed, Jun 11, 2008 at 9:46 PM, Karen Tracey <[EMAIL PROTECTED]> wrote:
> One thing I don't see mentioned anywhere is defect #6755 "Model Inheritance
> doesn't work in the admin" (whereas GenericForeignKey admin support is
> specifically called out). I don't know if #6755 is classified as must
On Wed, Jun 11, 2008 at 10:03 PM, Jacob Kaplan-Moss <
[EMAIL PROTECTED]> wrote:
>
> This is a call for comments on the proposed Django 1.0 roadmap and
> schedule.
>
> ...
> Must-have features
> --
>
...
> 2. Replacement of ``oldforms`` throughout Django.
>
> Nothing in Django
Very reasonable set for 1.0 release. The list of must-haves totally
matches my expectations. +1.
Thanks,
Eugene
Jacob Kaplan-Moss wrote:
> This is a call for comments on the proposed Django 1.0 roadmap and schedule.
>
> Note that though this is worded in the future perfect tense, it is only
This hits the nail right on the head. +1 from me.
On Jun 11, 2008, at 8:03 PM, Jacob Kaplan-Moss wrote:
> 2. Replacement of ``oldforms`` throughout Django.
>
> Nothing in Django 1.0 should rely on the deprecated ``oldforms``
> package.
> We'll need to replace ``oldforms`` usage in generic
On Wed, Jun 11, 2008 at 9:26 PM, Marty Alchin <[EMAIL PROTECTED]> wrote:
> I think I know what you mean here, but "dropped" sounds an awful lot
> like an all or nothing deal: either it makes it into 1.0 or it never
> makes it at all. It's probably best to clarify that "dropped" just
> means
Jacob Kaplan-Moss wrote:
This is a call for comments on the proposed Django 1.0 roadmap and schedule.
Note that though this is worded in the future perfect tense, it is only a draft;
I'm looking for feedback and comments from the community before the core
developers and I post a the final
I like it, but mainly that's because I'm not the "maybe" list, and I'm
sure I can get it done in time. I do have one suggestion, though.
On Wed, Jun 11, 2008 at 10:03 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> * "Maybe" features: things that *should* be in 1.0 and should be worked on
>
On Wed, Jun 11, 2008 at 9:13 PM, Russell Keith-Magee
<[EMAIL PROTECTED]> wrote:
>
> On Thu, Jun 12, 2008 at 10:03 AM, Jacob Kaplan-Moss
> <[EMAIL PROTECTED]> wrote:
>>
>> ``django.contrib.comments`` still uses ``oldforms`` as well, but there's
>> special situation here; see below.
>
> Jacob -
On Thu, Jun 12, 2008 at 10:03 AM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
>
> ``django.contrib.comments`` still uses ``oldforms`` as well, but there's
> special situation here; see below.
Jacob - unless I'm going blind, you've missed out the 'below' section
that this refers to.
Russ
This is a call for comments on the proposed Django 1.0 roadmap and schedule.
Note that though this is worded in the future perfect tense, it is only a draft;
I'm looking for feedback and comments from the community before the core
developers and I post a the final version of this document (which
71 matches
Mail list logo
