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
--~--~---------~--~----~------------~-------~--~----~
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 this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
