Moving towards Django 1.0

17 views
Skip to first unread message

Jacob Kaplan-Moss

unread,
Jan 12, 2007, 5:39:06 PM1/12/07
to django-d...@googlegroups.com
Howdy folks --

I think it's time to start a push towards releasing Django 1.0. What follows
are my thoughts about how I'd like this process to work.

== What does 1.0 mean for Django? ==

There's a lot of different things that "1.0" can mean. In many cases the
label refers to some arbitrary measure of code maturity, but that's usually
very indistinct. There's quite a bit of "1.0" software that's far less robust
than Django was at day 1; we could have called it "1.0" then and gotten away
with it, I think.

In the context of Django, though, 1.0 has always meant something more
concrete: forwards compatibility. Once we tag something as 1.0, we're
committing to maintaining API stability as described in the contributing HOWTO
(http://www.djangoproject.com/documentation/contributing/#official-releases).

This means that any API in 1.0 *must* continue to work until *at least* 1.2,
and we've been concerned about getting those APIs right before we carve them
into cement.

Now, though, we're getting pretty damn close. 0.95 stabilized the bulk of
Django's APIs (see http://www.djangoproject.com/documentation/api_stability/),
with a few exceptions.

So, for the purposes of my proposal, I'm calling 1.0 the point at which all of
Django's APIs stabilize. Note that this *doesn't* mean feature-completion --
there's some fascinating work (evolution, per-object-perms, etc.) that when
finished will make amazingly valuable additions to Django. None of that
influences the release of 1.0 in any way, so I'm going to ignore those kinds
of features until the very end.

So -- unstable APIs then. What do we have?

== Unstable APIs ==

* Forms: the newforms library is coming along nicely. There's some work that
remains, the bulk of which lies in converting the admin to use newforms
instead of manipulators. At that point, the transition can really be called
complete.

* Serialization: a few tickets (#2930, #2843, #2650, #2553, and perhaps a few
more) need to be reviewed and rolled in or rejected, but other than that I'm
willing to call this API stable.

* Authentication: Joseph Kocherhans proposed a couple of changes to the auth
code to better allow custom backends. I'm +1 on those changes, and in the
absence of any disagreement I'd say the community seems to agree as well.
Once that stuff goes in, I think we can pretty easily call the auth framework
solid -- any changes in the future could be made in a backwards-compatible way.

* Generic relations: two things need to happen here (a) they need to be moved
into the contrib app, and (b) They need to work in the admin. The second
probably should wait on the admin rewrite; the first can be done any time.

* Comments: I plan to rewrite this framework to use newforms, and in the
process drastically simplify it.

== Other must-haves ==

There's a few other things that aren't "unstable" per-se, but are must-haves
for 1.0. I know everyone's gonna have their own list -- and one of the
purposes of this thread is to find that list -- but I'd like to keep these
minimal. Here's my list of must-haves for 1.0:

* Oracle and SQLServer support. How do people -- especially core comitters --
feel about the Oracle sprint branch? I'd like to merge it; the general outline
of the Oracle backend should let the SQLServer folks go to town.

* Test fixtures. I think we're just waiting on Adrian's OK to check this in;
I'm +1 on Russ's patch on #2333.

== Handling breakage ==

A few of these things -- the last three, mostly -- will break (some to lots)
of code. Just doing it in some arbitrary SVN revision would suck.

So I think we should release a 0.96 in the next week or so, and make the all
the backwards-incompatible changes after 0.96. We should announce in as many
places as possible that trunk will be moving things around between 0.96 and
the next release.

Which brings me to...

== 1.0 roadmap ==

So, here's my roadmap for 1.0:

* Release 0.96
* Finalize all unstable APIs and must-haves referenced above.
* Release 1.0rc1
* Resolve (i.e. fix, reject, or defer) all tickets in Trac.
* Release rc2
* Call for and fix any large outstanding breakage still in rc2
* Release 1.0

I'm deliberately not mentioning any dates for any of the above, and I won't.
I think Adrian might have a timeline in mind and I'm glad to hear it, but I'm
not gonna jinx myself :)

== How should this work? ==

So that brings us to a process. Here's how I'd like it to work:

=== Step 1: feature-completion ===

I'd like to appoint a "leader" for each "topic" (unstable API and must-have).
This person will have checkin access to their area of interest so they'll
need to be someone who's already got checkin or someone who's skilled enough
to deserve it. This person can either tackle the issue alone or else form a
team to get it done. Here's my list -- any nominations for the missing slots?

* Forms: Adrian
* Serialization: Jacob
* Authentication: Joseph
* Generic relations: ?
* Comments: Jacob
* Oracle: ?
* SQLServer: ?
* Fixtures: Russ

Additionally: anyone who volunteers to be the Oracle or SQLServer leader needs
to commit to sticking around well after 1.0 to maintain those features. None
of the core devs can test those backends, so if they're going to be part of
Django they need champions.

=== Step 2: bug fixes ===

Once all the 1.0 features are done, we need to fix bugs.

I think this would be best done through a series of sprints, both physical or
virtual. Hopefully we can arrange a few sprints where some of the core devs
can physically gather together and check in patches, review tickets, etc etc etc.

I think we can put off planning these sprints in detail until step 1 is
complete; I'll just nominate Lawrence and Chicago as my #1 and #2 choices and
move on :)

=== Step 3: release ===

We'll need a release manager to make the final decisions about when/what to
release, which bugs are vital to be fixed, etc. This is about as far forward
as I've thought, though; I'm not sure who this should be, or exactly what
responsibilities s/he should have.

== Feedback ==

Well, have at it :)

Jacob

John Sutherland

unread,
Jan 12, 2007, 6:28:22 PM1/12/07
to django-d...@googlegroups.com
On 12 Jan 2007, at 22:39, Jacob Kaplan-Moss wrote:
> There's a few other things that aren't "unstable" per-se, but are
> must-haves
> for 1.0. I know everyone's gonna have their own list -- and one of
> the
> purposes of this thread is to find that list -- but I'd like to
> keep these
> minimal.

What's the story with model inheritance?

Cheers,
John.

--
http://sneeu.com/

David Zhou

unread,
Jan 12, 2007, 6:35:34 PM1/12/07
to django-d...@googlegroups.com

On Jan 12, 2007, at 5:39 PM, Jacob Kaplan-Moss wrote:

> == Feedback ==
>
> Well, have at it :)

How about the docs on the Django site and the Django book site?
Newforms, for example, is still fairly under documented, though
quickly improving. 1.0 is a big psychological milestone, and will
probably draw in a lot of people -- I think it'd be beneficial to
make sure all the documentation is in place before the big rush :)

---
David Zhou
da...@nodnod.net

inflector

unread,
Jan 12, 2007, 6:59:42 PM1/12/07
to Django developers
> == Other must-haves ==
>
> There's a few other things that aren't "unstable" per-se, but are must-haves
> for 1.0. I know everyone's gonna have their own list

As a noob I think you would be making a mistake without a simple Django
installer for Windows, one that installs everything needed along with a
non-trivial sample application that people can explore.

Since the 1.0 release will cause a lot of people to consider looking
seriously at Django and perhaps even Python for the first time, it make
sense to lower the barrier to actually doing something useful and
seeing how powerful Django really is. I wasn't sold until I had gone
through the tutorial.

Getting to the point of being able to start the tutorial is actually
more complicated than doing the tutorial. Though I admit it is not too
difficult, there are plenty of places where one can screw up with the
semi-manual approach currently required.

I'd be happy to take on the installer part if no one else better
qualified steps up. I would also be happy to deal with a non-trivial
example as soon as I have one. However, I am sure my use of
Python/Django idiom will be suboptimal and there is probably something
in existence that would be a better example.

One possibility is taking the Tutorial a bit further and having some
professional quality templates designed so that it looks impressive.
This way prospective users can see what the end result looks like and
then the tutorial can take them from scratch to building that example.
I can help out here as well if need be.

What sort of timeframe do you envision for 1.0 a few weeks, a few
months?

- Curtis

Malcolm Tredinnick

unread,
Jan 12, 2007, 7:02:02 PM1/12/07
to django-d...@googlegroups.com
On Fri, 2007-01-12 at 16:39 -0600, Jacob Kaplan-Moss wrote:
> Howdy folks --
>
> I think it's time to start a push towards releasing Django 1.0. What follows
> are my thoughts about how I'd like this process to work.

So I've been absent for a couple of months now with work and life
commitments, but things are getting back on track (woo-hoo -- once again
I will soon have no life.. hmm...wait a minute...). From the beginning
of February (around Feb 5), I will be back on deck to do a bunch more
Django work, so I feel I should be able to help out a bit here.


[...]


> == Other must-haves ==
>
> There's a few other things that aren't "unstable" per-se, but are must-haves
> for 1.0. I know everyone's gonna have their own list -- and one of the
> purposes of this thread is to find that list -- but I'd like to keep these
> minimal. Here's my list of must-haves for 1.0:
>
> * Oracle and SQLServer support. How do people -- especially core comitters --
> feel about the Oracle sprint branch? I'd like to merge it; the general outline
> of the Oracle backend should let the SQLServer folks go to town.
>
> * Test fixtures. I think we're just waiting on Adrian's OK to check this in;
> I'm +1 on Russ's patch on #2333.

* Model inheritance: This is top of my list to fix/finish. The
backwards-incompatible bit here (in a sense) is getting MI working at
all. The "under the covers" transparent portion that I was trying to do
first was refactoring the way we construct queries in order to construct
more efficient SQL (e.g. not using left outer joins when we don't need
them) and to be a bit more easily extensible for things like Oracle, SQL
Server and people who want to override query sets to add "group by" and
"having clauses". I'm going to reverse the order here: get MI working
(visible change), then go back to QuerySet stuff (which is functionally
invisible if you don't want to use the extra stuff). Part two here is
less important now, since the Oracle and SQL Server backends have made
do in other creative ways, although extensions to allow aggregations for
those who want them might make things helpful.

* Autoescaping: I think this needs to stay on the radar at least. We
came dangerously close to a consensus on this (both in discussions on
this list, based on Simon's proposal) and the discussions you, I and
Adrian had at OSCON. There is a patch in Trac that implements the whole
thing ( + tests + documentation), although it won't apply at the moment
because of the text fixture changes. I'll update the patch in early Feb,
but I think it might be worth having this in 1.0 -- particularly if we
want to have "on by default", since that is a real backwards-incompat
change -- but just as a marketing item, since it really is a bit of a
liability at the moment.

[Since it will no doubt come up, I'll just mention that I'm not
as enthused about SmileyChris's alternative AutoEscaping idea --
in the wiki -- because some of the points it addresses aren't
really problems, I feel, and is very difficult to integrate with
custom tags (or even things like linebreaksbr, etc). I may be
biased, though, since I liked Simon's original proposal.]

[...]


> == 1.0 roadmap ==
>
> So, here's my roadmap for 1.0:
>
> * Release 0.96
> * Finalize all unstable APIs and must-haves referenced above.
> * Release 1.0rc1
> * Resolve (i.e. fix, reject, or defer) all tickets in Trac.
> * Release rc2
> * Call for and fix any large outstanding breakage still in rc2
> * Release 1.0
>
> I'm deliberately not mentioning any dates for any of the above, and I won't.
> I think Adrian might have a timeline in mind and I'm glad to hear it, but I'm
> not gonna jinx myself :)

This plan is ambitious enough that dates will be fun to watch as they go
whizzing by. But having some kind of step-by-step and some momentum to
actually get to 1.0 is going to help us.

> == How should this work? ==
>
> So that brings us to a process. Here's how I'd like it to work:
>
> === Step 1: feature-completion ===
>
> I'd like to appoint a "leader" for each "topic" (unstable API and must-have).
> This person will have checkin access to their area of interest so they'll
> need to be someone who's already got checkin or someone who's skilled enough
> to deserve it. This person can either tackle the issue alone or else form a
> team to get it done. Here's my list -- any nominations for the missing slots?
>
> * Forms: Adrian
> * Serialization: Jacob
> * Authentication: Joseph
> * Generic relations: ?
> * Comments: Jacob
> * Oracle: ?
> * SQLServer: ?
> * Fixtures: Russ

I'm happy to take on Generic relations (at least the moving portion and
to work out the pieces needed for when we get the admin rewrite done).
I'm also happy to do model inheritance. And seriously, if you have other
items that need volunteers, just put my name in. I can make time in the
next couple of months.

I guess I'd also like to see "documentation coverage" as an item there:
each individual component has its documentation as part of the work done
on it, but we need to check we really are covering all bases and fill in
the places that we've said "will be done eventually". I'm happy to take
on that job -- it's just (virtual) paperwork, mostly, keeping lists of
what we are missing and what tickets exist in that arena (and then
checking off as Adrian adds contractions and proofreads things).

> Additionally: anyone who volunteers to be the Oracle or SQLServer leader needs
> to commit to sticking around well after 1.0 to maintain those features. None
> of the core devs can test those backends, so if they're going to be part of
> Django they need champions.
>
> === Step 2: bug fixes ===
>
> Once all the 1.0 features are done, we need to fix bugs.
>
> I think this would be best done through a series of sprints, both physical or
> virtual. Hopefully we can arrange a few sprints where some of the core devs
> can physically gather together and check in patches, review tickets, etc etc etc.
>
> I think we can put off planning these sprints in detail until step 1 is
> complete; I'll just nominate Lawrence and Chicago as my #1 and #2 choices and
> move on :)

If you can give as much notice as possible for these, I'd like to fly
over and be onsite. Virtual sprinting from another timezone is not
always easy, although I'll give it a go if that's all there is.

> === Step 3: release ===
>
> We'll need a release manager to make the final decisions about when/what to
> release, which bugs are vital to be fixed, etc. This is about as far forward
> as I've thought, though; I'm not sure who this should be, or exactly what
> responsibilities s/he should have.

Agreed. You are probably talking about two jobs there, though: a final
call on things (you or Adrian, I suspect) and somebody (the Key
Master... er Bugmaster) to track to the "release critical" bugs and keep
things organised both for hammering the worker bees and feeding the
decisions up to the Final Decision Maker (tm).

>
> == Feedback ==
>
> Well, have at it :)

Nice stuff, Jacob.

Cheers,
Malcolm


Don Arbow

unread,
Jan 12, 2007, 7:06:37 PM1/12/07
to django-d...@googlegroups.com


Wasn't this dependent on query refactoring that Malcolm was working on?

Don


Don Arbow

unread,
Jan 12, 2007, 7:19:07 PM1/12/07
to django-d...@googlegroups.com
On Jan 12, 2007, at 4:06 PM, Don Arbow wrote:

> Wasn't this dependent on query refactoring that Malcolm was working
> on?
>


Doh, I send my post and Malcolm's response arrives at the same time...

Don

Jacob Kaplan-Moss

unread,
Jan 12, 2007, 7:23:33 PM1/12/07
to django-d...@googlegroups.com
On 1/12/07 5:35 PM, David Zhou wrote:
> How about the docs on the Django site and the Django book site?

First, please consider the book somewhat separate from Django itself. Though
Adrian and I are the authors, and though we're involving the community as much
as possible, the release schedule for the book is independent from any plans
for Django. That is, we need to take the publisher's needs into account for
the book, but those needs shouldn't -- and won't -- influence whatever we
decide for Django itself.

That said...

> Newforms, for example, is still fairly under documented, though
> quickly improving.

1/22 should see the publication of the book chapter on newforms :)

> 1.0 is a big psychological milestone, and will
> probably draw in a lot of people -- I think it'd be beneficial to
> make sure all the documentation is in place before the big rush :)

Yes, this is a very good point. I've been considering "documentation" as part
of the "bug fixing" (i.e. stage 2); perhaps it's its own task and should be
added as part of the "finalization" (step 1) stuff.

Yeah, as I think about it, I think docs are important enough they need their
own "leader" as well. That person could additionally take control of the
documentation index -- which is getting a bit difficult to use -- and the FAQ.

I've added that task to my list.

Jacob

Jacob Kaplan-Moss

unread,
Jan 12, 2007, 7:25:52 PM1/12/07
to django-d...@googlegroups.com
On 1/12/07 5:59 PM, inflector wrote:
> As a noob I think you would be making a mistake without a simple Django
> installer for Windows, one that installs everything needed along with a
> non-trivial sample application that people can explore.

Good point. Eugene sent me a windows installer a while ago, but I didn't have
a chance to test it out and then I lost track of it....

Let's table this until closer to the release, but if you want to talk to him
and anyone else and start lining things up for a windows installer, we'd love
to have one.

Jacob

Jacob Kaplan-Moss

unread,
Jan 12, 2007, 7:39:48 PM1/12/07
to django-d...@googlegroups.com
On 1/12/07 6:02 PM, Malcolm Tredinnick wrote:
> So I've been absent for a couple of months now with work and life
> commitments, but things are getting back on track (woo-hoo -- once again
> I will soon have no life.. hmm...wait a minute...). From the beginning
> of February (around Feb 5), I will be back on deck to do a bunch more
> Django work, so I feel I should be able to help out a bit here.

Yay!

You of course shouldn't feel any obligations, but it'll be quite nice to have
your help :)

> * Model inheritance
[snip]

I actually had this on my original list, but then I took it off -- it seems to
me that allowing MI wouldn't break any existing code (just allow new code to,
you know, work correctly). If that's true, I'd be OK introducing it post-1.0

However, if I'm wrong then this does need to be on the roadmap for 1.0.

> * Autoescaping: I think this needs to stay on the radar at least. We
> came dangerously close to a consensus on this (both in discussions on
> this list, based on Simon's proposal) and the discussions you, I and
> Adrian had at OSCON.

Ah, yes :)

I think I'm really the only one who's still holding out for manual escaping,
so in the interests of Getting Things Done I'm gonna shut up about it. Is
there anyone besides me who *doesn't* want auto escaping (in some form) in
Django? If so, let's hear it now.

> There is a patch in Trac that implements the whole
> thing ( + tests + documentation), although it won't apply at the moment
> because of the text fixture changes. I'll update the patch in early Feb,

Cool - I look forward to playing with you

> This plan is ambitious enough that dates will be fun to watch as they go
> whizzing by. But having some kind of step-by-step and some momentum to
> actually get to 1.0 is going to help us.

Let's keep things abstract for a couple of days at least, but once we've got
the hit list for 1.0 ironed down, you're right that someone should set a timeline.

It's just not gonna be me :)

> I'm happy to take on Generic relations (at least the moving portion and
> to work out the pieces needed for when we get the admin rewrite done).

That's fantastic. I've got some code for the admin kicking around that should
be OK to adapt and finish off for newforms. I'll put you on my list as the
mover and I'll be the shaker (er, the admin guy).

> I guess I'd also like to see "documentation coverage" as an item there:

See my previous post about this -- I agree 100%.

> If you can give as much notice as possible for these, I'd like to fly
> over and be onsite. Virtual sprinting from another timezone is not
> always easy, although I'll give it a go if that's all there is.

Yeah, will do.

> Agreed. You are probably talking about two jobs there, though: a final
> call on things (you or Adrian, I suspect) and somebody (the Key
> Master... er Bugmaster) to track to the "release critical" bugs and keep
> things organised both for hammering the worker bees and feeding the
> decisions up to the Final Decision Maker (tm).

Ahhh - that's the part I hadn't quite figured out myself. Good call.

Keep it coming,

Jacob

Michael Radziej

unread,
Jan 12, 2007, 7:40:21 PM1/12/07
to django-d...@googlegroups.com
Jacob Kaplan-Moss schrieb:

> * Forms: the newforms library is coming along nicely. There's some work that
> remains, the bulk of which lies in converting the admin to use newforms
> instead of manipulators. At that point, the transition can really be called
> complete.

Adrian said that he wanted to make inline collections easier. I
thought that this is a real big thing, and will completely redefine
how the admin implements inline editing. And probably deeper. (Just
had a look at AutomaticManipulator.save ... gosh)

Not to forget: newforms will have a big influence on generic views,
too.


Michael


--
noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
Tel +49-911-9352-0 - Fax +49-911-9352-100

http://www.noris.de - The IT-Outsourcing Company

Jacob Kaplan-Moss

unread,
Jan 12, 2007, 7:43:54 PM1/12/07
to django-d...@googlegroups.com
On 1/12/07 6:40 PM, Michael Radziej wrote:
> Adrian said that he wanted to make inline collections easier. I
> thought that this is a real big thing, and will completely redefine
> how the admin implements inline editing. And probably deeper. (Just
> had a look at AutomaticManipulator.save ... gosh)

Heh.

Yeah, this is part of reworking the admin to use newforms. I think Adrian's
got a plan here, so I'll let him answer more completely if he wants :)

> Not to forget: newforms will have a big influence on generic views,
> too.

Good point; someone's going to need to rework those, as well.

Jacob

Jeremy Bowers

unread,
Jan 12, 2007, 7:55:30 PM1/12/07
to django-d...@googlegroups.com
Jacob Kaplan-Moss wrote:
> I'd like to appoint a "leader" for each "topic" (unstable API and must-have).
> This person will have checkin access to their area of interest so they'll
> need to be someone who's already got checkin or someone who's skilled enough
> to deserve it. This person can either tackle the issue alone or else form a
> team to get it done. Here's my list -- any nominations for the missing slots?
What about things that don't match any of those things? Should misc.
patches be discussed before or after .96?

Michael Radziej

unread,
Jan 12, 2007, 7:57:22 PM1/12/07
to django-d...@googlegroups.com
Jacob Kaplan-Moss schrieb:

> On 1/12/07 6:40 PM, Michael Radziej wrote:
>> Adrian said that he wanted to make inline collections easier. I
>> thought that this is a real big thing, and will completely redefine
>> how the admin implements inline editing. And probably deeper. (Just
>> had a look at AutomaticManipulator.save ... gosh)
>
> Heh.
>
> Yeah, this is part of reworking the admin to use newforms. I think Adrian's
> got a plan here, so I'll let him answer more completely if he wants :)

If he did, this thread would be overtaken by discussions about
newforms, widgets, and html vs. xhtml ;-)

Jacob Kaplan-Moss

unread,
Jan 12, 2007, 8:11:58 PM1/12/07
to django-d...@googlegroups.com
On 1/12/07 6:55 PM, Jeremy Bowers wrote:
> What about things that don't match any of those things? Should misc.
> patches be discussed before or after .96?

Well, you'll need to be a bit more specific about what "things" you're talking
about. I think, though, that there are three possibilities for any "thing":

* If Feature X absolutely can't be implamened post-1.0 without breaking 1.0
APIs, then it needs to be accepted or rejected now. This case covers BIG
features like, well, rewriting Django's form handling. I don't think that
there are many of these.

* If Feature X could be done post-1.0, a decision about it would be made
during the ticket triage process (step 2 in my outline). That decision will
be either "reject", "accept", or "defer" (to 1.1 or whatever).

* If X is a bug, it will be fixed before 1.0.

Does that answer your question?

Jacob

Chris Nelson

unread,
Jan 12, 2007, 8:15:30 PM1/12/07
to django-d...@googlegroups.com
Jacob Kaplan-Moss wrote:
> On 1/12/07 6:02 PM, Malcolm Tredinnick wrote:
>
>> * Autoescaping: I think this needs to stay on the radar at least. We
>> came dangerously close to a consensus on this (both in discussions on
>> this list, based on Simon's proposal) and the discussions you, I and
>> Adrian had at OSCON.
>>
>
> Ah, yes :)
>
> I think I'm really the only one who's still holding out for manual escaping,
> so in the interests of Getting Things Done I'm gonna shut up about it. Is
> there anyone besides me who *doesn't* want auto escaping (in some form) in
> Django? If so, let's hear it now.
>
>
I would prefer that auto-escaping didn't make it into Django. It may be
an overly utopian ideal, but I think
security issues, including escaping, should be a conscious effort
involving research and understanding of the
situation. Without that, it's like blindly adding bandaids to your
application hoping they'll keep the holes closed.

Besides, auto-escaping reminds me of PHP's "magic quotes" and we all
know how well that turned out... :)

Chris

Adrian Holovaty

unread,
Jan 12, 2007, 8:55:12 PM1/12/07
to django-d...@googlegroups.com
On 1/12/07, Chris Nelson <ch...@karma.net.nz> wrote:
> I would prefer that auto-escaping didn't make it into Django. It may be
> an overly utopian ideal, but I think
> security issues, including escaping, should be a conscious effort
> involving research and understanding of the
> situation. Without that, it's like blindly adding bandaids to your
> application hoping they'll keep the holes closed.
>
> Besides, auto-escaping reminds me of PHP's "magic quotes" and we all
> know how well that turned out... :)

This comment set off all of my
here-comes-a-200-message-mailing-list-saga alarms, so before anybody
responds to this, *please* start the response in another mailing-list
thread.

Adrian

--
Adrian Holovaty
holovaty.com | djangoproject.com

James Bennett

unread,
Jan 12, 2007, 10:27:51 PM1/12/07
to django-d...@googlegroups.com
On 1/12/07, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> Yeah, as I think about it, I think docs are important enough they need their
> own "leader" as well. That person could additionally take control of the
> documentation index -- which is getting a bit difficult to use -- and the FAQ.

I've volunteered in the past and will happily volunteer again to take
up maintenance and organization of the docs.

--
"May the forces of evil become confused on the way to your house."
-- George Carlin

Ville Säävuori

unread,
Jan 13, 2007, 3:49:05 AM1/13/07
to Django developers
It's good to see some push towards 1.0

> == Feedback ==

What about one-to-one relationships? They seem to have had a deprecated
status for some time now.

In addition to organizing the documentation, I'd also like to see some
cleaning up and reorganization in the wiki. It also should be at least
somewhat collaborative work, maybe some sprint weekend or similar. I
think that the wiki is a great and valuable addition to the official
docs, but it's getting very hard to navigate and find stuff as the
content keeps growing.

I'd like to help as much as I can, but I'm not very experienced
Python-developer, so it would be nice to have some tips here on the
list and maybe on the
http://code.djangoproject.com/wiki/LittleEasyImprovements page, too :)

Norjee

unread,
Jan 13, 2007, 9:50:32 AM1/13/07
to Django developers
The main thing i'm missing is a workable reversed url resolver. Or at
least an easy way to define/extend the current implementation. There
was already some discussion about it (see Proposal: Root view). As it
seems such a thing, while being said to be backwards compatible, change
the current way url resolving works it would be nice have it in 1.0.
(And it seems that Django is the only modern platform not have more
advanced reverse url lookup)

gabor

unread,
Jan 13, 2007, 10:00:56 AM1/13/07
to django-d...@googlegroups.com
Jacob Kaplan-Moss wrote:
> * Forms: the newforms library is coming along nicely. There's some work that
> remains, the bulk of which lies in converting the admin to use newforms
> instead of manipulators. At that point, the transition can really be called
> complete.


it seems that noone mentioned unicode in this discussion yet...

does this mean, that the plan is to have django-1.0 still use bytestrings?

because if yes, then i would recommend to "downgrade" newforms to
bytestrings too.

the reason is consistency...

if i'm not mistaken, newforms works internally in unicode, and also
outputs unicode... which is quite nice, but the problem is, the rest of
django is in bytestrings...

so, at the end, in a django-view:

- GET/POST is in bytestrings
- newforms outputs unicode
- the templates output bytestrings
- the db-api outputs bytestrings

it is true, that with various hacks the newforms can be used from the
bytestring-based templates, and also they can save models to the
bytestring-based db-api. but it is not nice.


the other way is to switch django to unicode completely.

from the past discussion it seems, that many people wanted to work on it
, patches were created, so i think the unicode-conversion could happen
in a reasonable time.

gabor

Michael Radziej

unread,
Jan 13, 2007, 2:25:07 PM1/13/07
to django-d...@googlegroups.com
Hi,

please don't forget that every feature that you propose and that gets
into the 1.0 list will delay 1.0. Everybody has their favorite pet, and
with any project and any milestone, its the same: everybody tries to
push their favorites in.

The most important goal of 1.0 are stable APIs, i.e. that in future
releases the APIs need to be compatible. So, I suggest to add features
only if they will break existing APIs, or if they don't hold up things
(and that means, somebody can provide high quality patches that can be
integrated easily). It will always be possible to add features that
introduce new APIs later.

Here's a summary of what I found about the proposed changes:

Changes
feature APIs? Implementation? Decision?
-------------------------------------------------------------------
newforms Yes No, but on the way Yes
serialization No No No
authentication Yes Yes Yes
generic relation Yes No Yes
comments No No, but jacob takes Yes
oracle No Almost Yes
test fixtures No Yes Yes
root views/url rev. Yes No No
autoescape No Almost Almost

Remarks:

'Changes API' referes to making an incompatible change to the API.

'Decision': I've taken Jacob's or Adrian's statements as a decision
whether about how this feature should be done and whether it is ripe for
1.0. There's a good chance left that I misunderstood (sorry).

Specifics:

Serialization: #2930 has not been decided and does not include a patch.
#2843 is not changes the API only in a compatible way and there is no
decision in the ticket. #2650 is a bug and not an enhancement, and it
does not include a patch but complete files (but bug fixes should go in
1.0 anyway, if possible). #2553 proposes to make generic views respond
in formats other than html, and it does not go into details nor does it
include a patch. From the description I couldn't find out what it
actually proposes, but it looks like a compatible change.

Comments: Jacob plans to rewrite them for newforms. I'd say this change
actually belongs into the category 'newforms'. I'm not entirely
convinced that it is necessary to rewrite the comments in 1.0, though.
Other than the changes in admin, the comments system rewrite shouldn't
directly influence the API of newforms.

Oracle: While it doesn't change APIs, having an oracle backend is great
for the 1.0 release, even if it doesn't contribute to the #1 goal. And
there is great impetus behind it.

The root view proposal was blocked by the problem of url reversal. A few
possible solutions have been brought up that had some disadvantages, and
nobody of the core team has commented on this.

Autoescape only changed APIs if it was on by default. But I've followed
the discussion very closely, and I'm sure that the main reaction of the
community was strictly against this. autoescape is my own favorite pet,
but when I apply my own criteria, it wouldn't be a candidate for 1.0.
One could argue that it will deeply affect the way templates are written
and that they are an important step to make django applications safe,
but the consensus about it was not that strong. Or do we want to use it
in the admin?


I'm creating a wiki page for this summary (with some more information).
Can somebody fill me in about the tickets for authentication?

Michael

Rob Hudson

unread,
Jan 13, 2007, 4:00:34 PM1/13/07
to Django developers
Jacob Kaplan-Moss wrote:
> Good point. Eugene sent me a windows installer a while ago, but I didn't have
> a chance to test it out and then I lost track of it....
>
> Let's table this until closer to the release, but if you want to talk to him
> and anyone else and start lining things up for a windows installer, we'd love
> to have one.

I'm pretty comfortable with the Nullsoft Installer (NSIS: nsis.sf.net).
If Django decides to use that, I'd be happy to help.

Should we start a separate thread to answer questions like:

* Should we use default Python or something like Portable Python?
* Assume SQLite?
* Install any add-ons (like Markdown or Textile)?

-Rob

Jacob Kaplan-Moss

unread,
Jan 13, 2007, 6:20:08 PM1/13/07
to django-d...@googlegroups.com
On 1/13/07 1:25 PM, Michael Radziej wrote:
> I'm creating a wiki page for this summary (with some more information).

Awesome. I've been keeping a similar list, so I'll fill in what I've got as well.

> Can somebody fill me in about the tickets for authentication?

I'm sure sure ticket-wise, but Joseph posted his plans to the list a couple of
days ago.

Jacob

Michael Radziej

unread,
Jan 13, 2007, 7:32:12 PM1/13/07
to django-d...@googlegroups.com
Hi,

Jacob Kaplan-Moss schrieb:


> On 1/13/07 1:25 PM, Michael Radziej wrote:
>> I'm creating a wiki page for this summary (with some more information).
>
> Awesome. I've been keeping a similar list, so I'll fill in what I've got
> as well.

OK, I'm done.

http://code.djangoproject.com/wiki/VersionOneFeatures

I have left the old contents that have seen the last edit in July in
place under a section 'obsolete' to move them around as the plans become
more clearer.

In addition to my preceding posting, I've added the items model
inheritance, ms sql server and windows installer, which I've somehow
overlooked.

> I'm sure sure ticket-wise, but Joseph posted his plans to the list a
> couple of days ago.

Hmm. I'll add it later ;-)

Michael


Eugene Lazutkin

unread,
Jan 13, 2007, 10:06:46 PM1/13/07
to django-d...@googlegroups.com
Rob Hudson wrote:
> Jacob Kaplan-Moss wrote:
>> Good point. Eugene sent me a windows installer a while ago, but I didn't have
>> a chance to test it out and then I lost track of it....
>>
>> Let's table this until closer to the release, but if you want to talk to him
>> and anyone else and start lining things up for a windows installer, we'd love
>> to have one.
>
> I'm pretty comfortable with the Nullsoft Installer (NSIS: nsis.sf.net).
> If Django decides to use that, I'd be happy to help.

NSIS is my favorite, and it was my first choice. Finally I decided to
use bdist_nsi (http://bdist-nsi.sourceforge.net/) because:

1) It uses NSIS to produce an installer.
2) It is based on distutil => it was super easy to create an installer
for existing Django 0.95 package.

The only non-standard thing I did was to replace bdist_nsi's default art
with Django-related one.

> Should we start a separate thread to answer questions like:
>
> * Should we use default Python or something like Portable Python?
> * Assume SQLite?
> * Install any add-ons (like Markdown or Textile)?

I was pondering these questions myself and decided against bundling ---
IMHO selecting all these packages is a way too intimate process to
automate. But I may be wrong.

Thanks,

Eugene

Curtis Faith

unread,
Jan 13, 2007, 10:19:52 PM1/13/07
to Django developers
> > Should we start a separate thread to answer questions like:
> >
> > * Should we use default Python or something like Portable Python?
> > * Assume SQLite?
> > * Install any add-ons (like Markdown or Textile)?
>
> I was pondering these questions myself and decided against bundling ---
> IMHO selecting all these packages is a way too intimate process to
> automate. But I may be wrong.

There are really at least two distinct audiences for an installer:
experienced python users who will likely have a database and python
version installed along with various add ons, and new python users who
may be thinking about moving from LAMP (where the P is PHP) to either
Ruby on Rails or hopefully Django and Python.

For the first class of users, like most anyone reading this list, the
ability to install just Django would be good. For the second class of
users, a default set of options that would install SQLite and a default
Python along with any typical add ons is important.

It is important to lower the barrier for creating a side-by-side
comparison for anyone considering a move off of PHP to something
better. At this point, most people will probably look at Python and
Ruby. It would be good if their experience during that process was
favorable because the Django installer took care of the details for the
purposes of an evaluation of the framework.

- Curtis

Honza Král

unread,
Jan 13, 2007, 10:42:08 PM1/13/07
to django-d...@googlegroups.com
On 1/14/07, Curtis Faith <cur...@tradingblox.com> wrote:
>
> > > Should we start a separate thread to answer questions like:
> > >
> > > * Should we use default Python or something like Portable Python?
> > > * Assume SQLite?
> > > * Install any add-ons (like Markdown or Textile)?
> >
> > I was pondering these questions myself and decided against bundling ---
> > IMHO selecting all these packages is a way too intimate process to
> > automate. But I may be wrong.
>
> There are really at least two distinct audiences for an installer:
> experienced python users who will likely have a database and python
> version installed along with various add ons, and new python users who
> may be thinking about moving from LAMP (where the P is PHP) to either
> Ruby on Rails or hopefully Django and Python.
>
> For the first class of users, like most anyone reading this list, the
> ability to install just Django would be good. For the second class of
> users, a default set of options that would install SQLite and a default
> Python along with any typical add ons is important.

I have to agree on this one. Even though I am 100% microsoft free
(linux) and have no trouble installing django manually, I still have
problems when I need to work with somebody (designer or some other
developer). It would be VERY useful for me to point them to the
installer and not to worry if they can/will install all the necessary
apps to go along (DB, backend etc.)

I don't thing this installer will be used for production deployment
(maybe I am naive, but the idea of a windows server makes me a bit
uneasy), but rather for installations on desktops for developers and
designers in order to be able to work on their machine without a
server or even an internet connection.

>
> It is important to lower the barrier for creating a side-by-side
> comparison for anyone considering a move off of PHP to something
> better. At this point, most people will probably look at Python and
> Ruby. It would be good if their experience during that process was
> favorable because the Django installer took care of the details for the
> purposes of an evaluation of the framework.
>
> - Curtis
>
>
> >
>


--
Honza Král
E-Mail: Honza...@gmail.com
ICQ#: 107471613
Phone: +420 606 678585

Rob Hudson

unread,
Jan 14, 2007, 5:21:43 PM1/14/07
to Django developers
> There are really at least two distinct audiences for an installer:
> experienced python users who will likely have a database and python
> version installed along with various add ons, and new python users who
> may be thinking about moving from LAMP (where the P is PHP) to either
> Ruby on Rails or hopefully Django and Python.

I think we should target the new users and create the installer to
install a sort of "sandboxed" Django -- Django intended to use its
internal web server for those who just want to download and play.

To that end, I think including SQLite and a few other common bits would
be useful just to test out Django and develop against.

My 2 cents.

-Rob

Rob Hudson

unread,
Jan 14, 2007, 5:22:59 PM1/14/07
to Django developers
PS: This could also be used as an example of how to build an installer
for your app to send to someone for reviews. Something we're going to
need where I work in the not so distant future.

Honza Král

unread,
Jan 14, 2007, 6:26:33 PM1/14/07
to django-d...@googlegroups.com

I don't like the idea of promoting installation of django app on
windows/SQLite... it just feels wrong - it is nowhere near
environment suitable for deployment of a web application and to hint
otherwise is just not right.

If you want to deploy web application on desktop and you know what you
are doing, fine, do it, but please do not tell others that this is OK.
Its not. If you want to run application on a desktop you use desktop
application, not a web app with built-in webserver and DB (neither of
which was built for production use).

just my 2c's.

Honza

zenx

unread,
Jan 15, 2007, 4:35:48 AM1/15/07
to Django developers
>I'm happy to take on Generic relations (at least the moving portion and
>to work out the pieces needed for when we get the admin rewrite done).
>I'm also happy to do model inheritance. And seriously, if you have other
>items that need volunteers, just put my name in. I can make time in the
>next couple of months.

Malcolm,
I think this might be useful:
http://net-x.org/weblog/2006/dec/19/django-generic-relations-made-easier-part-2/

It's an implementation of generic relations in the admin. I have tried
it and it seems to be a good start point.

nesh

unread,
Jan 15, 2007, 6:40:04 AM1/15/07
to django-d...@googlegroups.com
* Jacob Kaplan-Moss wrote, On 12.01.2007 23:39:
> == Feedback ==

> Well, have at it :)

What about model level validation? With coming of the new forms model level validation is becoming a must.

New forms only validate *field* data with no provision to validate unique (or unique_together) constraints or any other
constraints which are model related. Also tying some of this type of validation with the newforms will couple them with
models which is a Bad Thing(tm).

So, IMHO, with a moving to the new forms we also must move validation where it belongs -- in the models.

--
Nebojša Đorđević - nesh, ICQ#43799892
Studio Quattro - Niš - Serbia
http://studioquattro.biz/ | http://trac.studioquattro.biz/djangoutils/
Registered Linux User 282159 [http://counter.li.org]

viestards

unread,
Jan 15, 2007, 8:27:01 AM1/15/07
to django-d...@googlegroups.com
On 1/14/07, Eugene Lazutkin <eugene....@gmail.com> wrote:
> > * Should we use default Python or something like Portable Python?
> > * Assume SQLite?
> > * Install any add-ons (like Markdown or Textile)?
>
> I was pondering these questions myself and decided against bundling ---
> IMHO selecting all these packages is a way too intimate process to
> automate. But I may be wrong.

IMO we have to include Python and PySQLite but they are not installed
by default, you can select them using full install. Of course there
must be workaround if there is Python and PySQLite installed and it
requires some work,but it will help much to someone new to Python and
Django.

> Thanks,
>
> Eugene

Russell Keith-Magee

unread,
Jan 15, 2007, 12:48:54 PM1/15/07
to django-d...@googlegroups.com
On 1/13/07, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
>
> Howdy folks --
>
> I think it's time to start a push towards releasing Django 1.0. What follows
> are my thoughts about how I'd like this process to work.
...
> == Other must-haves ==
>
> * Test fixtures. I think we're just waiting on Adrian's OK to check this in;
> I'm +1 on Russ's patch on #2333.

It should be noted that the patch on the ticket isn't completely up to
date. There are a few minor changes that resulted from our django-dev
discussion when I submitted the original patch. I've implemented most
of the changes, but I haven't had a chance to update the patch
attached to the ticket. I'm currently in Malvern in the UK on business
(side note - any Djangonistas in the area that are up for a pint?
Email me off-list) so I don't have access to my development box, but I
will update the patch as soon as I get a chance (probably a week or
so).

I'd also be keen on seeing model inheritance added to this list. I
would very much like to avoid releasing v1.0 with the the qualifier
that is currently attached to the documenatation for the
OneToOneField. However, adding model inheritance to the list this
depends on the extent of Malcolm's progress, and his judgement as to
the extent to which backwards incompatibility is an issue. I defer to
my learned colleague.

> == Handling breakage ==
> So I think we should release a 0.96 in the next week or so, and make the all
> the backwards-incompatible changes after 0.96. We should announce in as many
> places as possible that trunk will be moving things around between 0.96 and
> the next release.

This should also coordinate with the previously advertised plans for
newforms (top of page of
http://www.djangoproject.com/documentation/newforms/ ); by that plan,
0.96 would be the last release with the old forms, with 1.0 moving
newforms to forms, and removing oldforms altogether.

> So, here's my roadmap for 1.0:

I'm happy to finish off the fixtures thing and manage its introduction
to trunk. I doubt I'll be able to attend a physical sprint unless it
accidentally corresponds with a business trip, or unless everyone
comes to Perth, Western Australia for a holiday. Time-zones
permitting, I will try to make a virtual sprint.

Regarding the Oracle backend - I have a Django project at work that is
about to start and needs to use Oracle, so I can provide a testbed for
the Oracle backend in the wild. I'm a little hesitant to offer to
champion the backend long term because I'm not directly working on the
project myself, and I don't know how long our contractual engagement
is.

Other than that, I'm +1 to the rest of the strategy. Here's to
knocking this all off quickly so we can hold our heads high in the
pride we share in conforming to an aribitrary numerical nomenclature
:-)

Yours,
Russ Magee %-)

twilliams

unread,
Jan 15, 2007, 2:51:02 PM1/15/07
to Django developers
> Changes
> feature APIs? Implementation? Decision?
> -------------------------------------------------------------------
> newforms Yes No, but on the way Yes
> serialization No No No
> authentication Yes Yes Yes
> generic relation Yes No Yes
> comments No No, but jacob takes Yes
> oracle No Almost Yes
> test fixtures No Yes Yes
> root views/url rev. Yes No No
> autoescape No Almost Almost
>
> Comments: Jacob plans to rewrite them for newforms. I'd say this change
> actually belongs into the category 'newforms'. I'm not entirely
> convinced that it is necessary to rewrite the comments in 1.0, though.
> Other than the changes in admin, the comments system rewrite shouldn't
> directly influence the API of newforms.

There had been some discussion in late October regarding upcoming
changes to the Comments API and how it might look under 1.0 once
newforms was in place. Is the intention to keep the *model* for
Comment and FreeComment the same while using newforms to revise
view/template logic? Some ideas for changing the underlying structure
included:

* merging Comment and FreeComment
* supplying an abstract class and deriving Comment and FreeComment (and
potentially other user-derived Comment classes) from this class. Does
this depend on ModelInheritance? Seems so.
* setting up an API that "Comment" implementations can respond to. In
essence, I think the suggestion was to try and duck type comments.

I cannot tell if the previous discussion had ever been resolved.
Jacob, your thoughts? I have noticed a few discussions around the
hacking of FreeComment and I wonder where this piece, in particular, is
going.

Max Derkachev

unread,
Jan 17, 2007, 9:27:43 AM1/17/07
to Django developers
There were a lot of threads concerning unicodification.
It's in high demand by a great number of people, and there are many
willing to contribute.
There are virtualy no opposition.
Adrian once mentioned that "we should do it, and if we should, we
should do it before 1.0".

The Unicode haven't been mentioned in your list and haven't made to
http://code.djangoproject.com/wiki/VersionOneFeatures

http://groups-beta.google.com/group/django-developers/browse_frm/thread/1debd2337965a765
http://groups-beta.google.com/group/django-developers/browse_frm/thread/62681568a157b240


Regards,
Max Derkachev

rokcl...@gmail.com

unread,
Feb 6, 2007, 12:51:34 AM2/6/07
to Django developers
I have significant experience with MS SQL server 2000, and have access
to an instance to test against. I have found very little
documentation on Trac about this in tickets or the wiki. I am also
willing to help with Windows installers (NSIS is my recommended
tool). I gather that SQL server support is a slightly higher priority
than a Windows installer? Does MS SQL currently have someone heading
that effort? Where should I start?

On Jan 12, 5:39 pm, Jacob Kaplan-Moss <j...@jacobian.org> wrote:
> Howdy folks --
>
> I think it's time to start a push towards releasing Django 1.0. What follows
> are my thoughts about how I'd like this process to work.
>

> == What does 1.0 mean for Django? ==
>
> There's a lot of different things that "1.0" can mean. In many cases the
> label refers to some arbitrary measure of code maturity, but that's usually
> very indistinct. There's quite a bit of "1.0" software that's far less robust
> than Django was at day 1; we could have called it "1.0" then and gotten away
> with it, I think.
>
> In the context of Django, though, 1.0 has always meant something more
> concrete: forwards compatibility. Once we tag something as 1.0, we're
> committing to maintaining API stability as described in the contributing HOWTO
> (http://www.djangoproject.com/documentation/contributing/#official-rel...).
>
> This means that any API in 1.0 *must* continue to work until *at least* 1.2,
> and we've been concerned about getting those APIs right before we carve them
> into cement.
>
> Now, though, we're getting pretty damn close. 0.95 stabilized the bulk of
> Django's APIs (seehttp://www.djangoproject.com/documentation/api_stability/),
> with a few exceptions.
>
> So, for the purposes of my proposal, I'm calling 1.0 the point at which all of
> Django's APIs stabilize. Note that this *doesn't* mean feature-completion --
> there's some fascinating work (evolution, per-object-perms, etc.) that when
> finished will make amazingly valuable additions to Django. None of that
> influences the release of 1.0 in any way, so I'm going to ignore those kinds
> of features until the very end.
>
> So -- unstable APIs then. What do we have?
>
> == Unstable APIs ==


>
> * Forms: the newforms library is coming along nicely. There's some work that
> remains, the bulk of which lies in converting the admin to use newforms
> instead of manipulators. At that point, the transition can really be called
> complete.
>

> * Serialization: a few tickets (#2930, #2843, #2650, #2553, and perhaps a few
> more) need to be reviewed and rolled in or rejected, but other than that I'm
> willing to call this API stable.
>
> * Authentication: Joseph Kocherhans proposed a couple of changes to the auth
> code to better allow custom backends. I'm +1 on those changes, and in the
> absence of any disagreement I'd say the community seems to agree as well.
> Once that stuff goes in, I think we can pretty easily call the auth framework
> solid -- any changes in the future could be made in a backwards-compatible way.
>
> * Generic relations: two things need to happen here (a) they need to be moved
> into the contrib app, and (b) They need to work in the admin. The second
> probably should wait on the admin rewrite; the first can be done any time.
>
> * Comments: I plan to rewrite this framework to use newforms, and in the
> process drastically simplify it.
>
> == Other must-haves ==
>
> There's a few other things that aren't "unstable" per-se, but are must-haves
> for 1.0. I know everyone's gonna have their own list -- and one of the
> purposes of this thread is to find that list -- but I'd like to keep these
> minimal. Here's my list of must-haves for 1.0:
>
> * Oracle and SQLServer support. How do people -- especially core comitters --
> feel about the Oracle sprint branch? I'd like to merge it; the general outline
> of the Oracle backend should let the SQLServer folks go to town.


>
> * Test fixtures. I think we're just waiting on Adrian's OK to check this in;
> I'm +1 on Russ's patch on #2333.
>

> == Handling breakage ==
>
> A few of these things -- the last three, mostly -- will break (some to lots)
> of code. Just doing it in some arbitrary SVN revision would suck.


>
> So I think we should release a 0.96 in the next week or so, and make the all
> the backwards-incompatible changes after 0.96. We should announce in as many
> places as possible that trunk will be moving things around between 0.96 and
> the next release.
>

> Which brings me to...
>
> == 1.0 roadmap ==


>
> So, here's my roadmap for 1.0:
>

> * Release 0.96
> * Finalize all unstable APIs and must-haves referenced above.
> * Release 1.0rc1
> * Resolve (i.e. fix, reject, or defer) all tickets in Trac.
> * Release rc2
> * Call for and fix any large outstanding breakage still in rc2
> * Release 1.0
>
> I'm deliberately not mentioning any dates for any of the above, and I won't.
> I think Adrian might have a timeline in mind and I'm glad to hear it, but I'm
> not gonna jinx myself :)
>
> == How should this work? ==
>
> So that brings us to a process. Here's how I'd like it to work:
>
> === Step 1: feature-completion ===


>
> I'd like to appoint a "leader" for each "topic" (unstable API and must-have).
> This person will have checkin access to their area of interest so they'll
> need to be someone who's already got checkin or someone who's skilled enough
> to deserve it. This person can either tackle the issue alone or else form a
> team to get it done. Here's my list -- any nominations for the missing slots?
>

> * Forms: Adrian
> * Serialization: Jacob
> * Authentication: Joseph
> * Generic relations: ?
> * Comments: Jacob
> * Oracle: ?
> * SQLServer: ?
> * Fixtures: Russ
>
> Additionally: anyone who volunteers to be the Oracle or SQLServer leader needs
> to commit to sticking around well after 1.0 to maintain those features. None
> of the core devs can test those backends, so if they're going to be part of
> Django they need champions.
>
> === Step 2: bug fixes ===
>
> Once all the 1.0 features are done, we need to fix bugs.
>
> I think this would be best done through a series of sprints, both physical or
> virtual. Hopefully we can arrange a few sprints where some of the core devs
> can physically gather together and check in patches, review tickets, etc etc etc.
>
> I think we can put off planning these sprints in detail until step 1 is
> complete; I'll just nominate Lawrence and Chicago as my #1 and #2 choices and
> move on :)
>
> === Step 3: release ===
>
> We'll need a release manager to make the final decisions about when/what to
> release, which bugs are vital to be fixed, etc. This is about as far forward
> as I've thought, though; I'm not sure who this should be, or exactly what
> responsibilities s/he should have.


>
> == Feedback ==
>
> Well, have at it :)
>

> Jacob

Reply all
Reply to author
Forward
0 new messages