Django 1.2 roadmap and schedule
Jacob Kaplan-Moss
Yup, it's that time again!
For the tl;dr-ers, here's the short version:
* We're aiming to release Django 1.2 on March 9th, 2010.
* We'll begin voting on features for 1.2 very soon (today or tomorrow).
* We're modifying the process slightly from last time; in particular,
we're going to be *much* more hard-nosed about dropping features to
meet deadlines. Practically, this means no more "must-haves" this time
'round.
Full details, and a full schedule, are at
http://code.djangoproject.com/wiki/Version1.2Roadmap (thanks to Russ;
he wrote most of that).
I do want to take a moment to highlight what we're doing different
this time around. As y'all probably noticed, we missed the 1.1 release
date rather badly (i.e. by nearly 3 months). That's not a good thing;
if we're going to be doing date-based releases, we need to actually
hit the dates we specify.
The main problem, it seems, was that we simply put too much weight
into the idea of "must-have" features. Those are really hard to pull
off in all-volunteer communities such as ours; you never know when a
contributor will change jobs, or go through an acquisition, or have a
baby, or just simply lose interest and wander off.
Really, the only way to deal with this pragmatically is to drop the
idea of "must-have" features. If you think a feature should be in
v1.2, you need to commit to working on it. That's it.
We're still gathering feature requests for 1.2 (see
http://code.djangoproject.com/wiki/Version1.2Features), but we're
going to work voting differently. Instead of categorizing features
into "must-have / should-have / pony" categories, we're going to
simply mark them high/medium/low priority, meaning:
* High Priority: A core developer is actively engaged in the ticket.
* Medium Priority: A core developer is interested in the ticket, but
requires someone to do the work.
* Low priority: No core developer has declared a specific interest,
but if a good implementation appears, that may change.
The voting process plus the use of "High Priority" rather than "Must
have" aims to reflect the reality of Django development. Any finished
code will be committed, regardless of schedule. If a feature still
needs some design work, that's fine - as long as the work is done by
the feature freeze.
Again, for all the full details read
http://code.djangoproject.com/wiki/Version1.2Roadmap. I'll be watching
email and on IRC all day to answer questions, and I'll have a form for
voting on 1.2 features up shortly; watch this space.
Jacob
Vinay Sajip
> We're still gathering feature requests for 1.2 (seehttp://code.djangoproject.com/wiki/Version1.2Features), but we're
> into "must-have / should-have / pony" categories, we're going to
> simply mark them high/medium/low priority, meaning:
early point in the 1.1 cycle was considered as a possibility for
inclusion. I'd like to add this in as a feature request, so should I
just go ahead and update the Wiki page (assuming I can)? If so, which
category should I add it in? I don't think it counts as a major
feature, but people have characterised it as that before (in terms of
impact rather than features).
The patch was last updated to work cleanly with r10759 in May 09 and
though I haven't kept it updated recently, I have no problems
committing to doing any further work needed to get it into 1.2.
Regards,
Vinay Sajip
Russell Keith-Magee
>
> On Oct 8, 6:44 pm, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
>> We're still gathering feature requests for 1.2 (seehttp://code.djangoproject.com/wiki/Version1.2Features), but we're
>> going to work voting differently. Instead of categorizing features
>> into "must-have / should-have / pony" categories, we're going to
>> simply mark them high/medium/low priority, meaning:
>
> I'd like to know about the app_label patch on #3591, which at one
> early point in the 1.1 cycle was considered as a possibility for
> inclusion.
>
> I'd like to add this in as a feature request, so should I
> just go ahead and update the Wiki page (assuming I can)? If so, which
> category should I add it in? I don't think it counts as a major
> feature, but people have characterised it as that before (in terms of
> impact rather than features).
While it may not be *technically* too late to get the feature on the
voting list, my Magic 8-ball predicts that any vote on #3591 will have
the same result as last time - Rejected, needs more design work.
All the serious proposals for v1.2 on the wiki have had extensive (and
recent) discussion threads on django-developers. Can you explain
exactly what has changed since ORM-23 was rejected? The most recent
discussion of #3591 that I can find is discussion that explained why
the proposal was rejected for v1.1. We're near the end of the
discussion phase for v1.2, and to the best of my knowledge, this isn't
a major itch for anyone in the core. You have just a few short days in
which to convince one of us that it should be.
> The patch was last updated to work cleanly with r10759 in May 09 and
> though I haven't kept it updated recently, I have no problems
> committing to doing any further work needed to get it into 1.2.
A clean patch isn't the issue. Having a vetted design is.
At this point, I would suggest that v1.3 is a more realistic goal -
with the advisory that you try to get the discussion going at the
_start_ of the discussion phase, not at the end.
Yours,
Russ Magee %-)
Vinay Sajip
> voting list, my Magic 8-ball predicts that any vote on #3591 will have
> the same result as last time - Rejected, needs more design work.
>
> All the serious proposals for v1.2 on the wiki have had extensive (and
> recent) discussion threads on django-developers. Can you explain
> exactly what has changed since ORM-23 was rejected? The most recent
> discussion of #3591 that I can find is discussion that explained why
> the proposal was rejected for v1.1. We're near the end of the
2008, then as I recall, the main reason for rejection was effectively
not enough core developer time to look at the feature in more detail,
given other priorities.
> discussion phase for v1.2, and to the best of my knowledge, this isn't
> a major itch for anyone in the core. You have just a few short days in
> which to convince one of us that it should be.
only noticed any specifics about 1.2 from Simon's post about logging
in Django, and then this thread. I don't propose to waste anyone's
time trying to convince you to look at this, as it's not a major itch
for any of you.
> > The patch was last updated to work cleanly with r10759 in May 09 and
> > though I haven't kept it updated recently, I have no problems
> > committing to doing any further work needed to get it into 1.2.
>
> A clean patch isn't the issue. Having a vetted design is.
vetting, given that there are other things with higher priorities.
> At this point, I would suggest that v1.3 is a more realistic goal -
> with the advisory that you try to get the discussion going at the
> _start_ of the discussion phase, not at the end.
I must have missed a signpost which said something like, "time to put
our thinking caps on for 1.2" and only realised that the planning was
under way when I saw Jacob's post of two days ago which does say,
"We're still gathering feature requests for 1.2".
So I'm sorry I got the impression from that statement that we had more
than just a few days to go. And I'm not sure that it matters anyway,
as from what I can tell, it's not really a core dev priority and the
main roadblock is lack of core dev time to discuss/guide around what
are perceived as outstanding issues.
Regards,
Vinay Sajip
Russell Keith-Magee
>
>> While it may not be *technically* too late to get the feature on the
>> voting list, my Magic 8-ball predicts that any vote on #3591 will have
>> the same result as last time - Rejected, needs more design work.
>>
>> All the serious proposals for v1.2 on the wiki have had extensive (and
>> recent) discussion threads on django-developers. Can you explain
>> exactly what has changed since ORM-23 was rejected? The most recent
>> discussion of #3591 that I can find is discussion that explained why
>> the proposal was rejected for v1.1. We're near the end of the
>
> If you're referring to the discussion which happened in mid-November
> 2008, then as I recall, the main reason for rejection was effectively
> not enough core developer time to look at the feature in more detail,
> given other priorities.
Quoth Malcolm:
"""
My -1 is because of basically the same thing Jannis has pointed out (and
as I mentioned in my comment). There's a big ticket with various
proposals and at some point last year Adrian mentioned he had another
idea and that led to a group discussion at PyCon this year which raised
a bunch of issues to be resolved. I don't feel there's a great consensus
about the approach yet. This isn't something that should be half-baked,
so if there's still unresolved items with no buy-in from any maintainer
(and I haven't seen that yet), then I'm not going to be in favour.
"""
It isn't just a matter of core developers not having enough time to
review a specific patch - it's that there is a lot more design work
required.
We need to be clear about exactly what the feature selection process
means. We aren't having a vote to decide what the core developers will
work on over the next few months. What we are voting on is the list of
features that are already sufficiently well developed that with a
little more community development, and a little bit of attention from
the core, will be in a position to be committed to trunk.
In the case of #3591, there is still a lot of design work required.
That design discussion needs to happen before we know if we're going
to be in a position to commit code. For example, if the only way to
implement the feature well is to introduce major backwards
incompatibilities in the way applications are loaded, we may need to
defer the implementation until v2.0 when we are in a position to break
backwards compatibility.
>> discussion phase for v1.2, and to the best of my knowledge, this isn't
>> a major itch for anyone in the core. You have just a few short days in
>> which to convince one of us that it should be.
>
> Sorry if I'm late to the party. I don't follow the list daily, and I
> only noticed any specifics about 1.2 from Simon's post about logging
> in Django, and then this thread. I don't propose to waste anyone's
> time trying to convince you to look at this, as it's not a major itch
> for any of you.
I will admit that we (the core) haven't done a great job officially
communicating 'state changes' like the start of the feature discussion
phase. When you're in the middle of things, the need to put out blog
posts etc isn't always apparent. This is something that we as a
community (and the core team in particular) need to improve on.
For the record, the Django release cycle is documented here:
http://docs.djangoproject.com/en/dev/internals/release-process/#release-cycle
Given that almost 3 months has past since the release of v1.1, it's
safe to assume that we're nearing the end of the proposal phase.
>> > The patch was last updated to work cleanly with r10759 in May 09 and
>> > though I haven't kept it updated recently, I have no problems
>> > committing to doing any further work needed to get it into 1.2.
>>
>> A clean patch isn't the issue. Having a vetted design is.
>
> Yes, and I understand that you don't have enough time to spend on this
> vetting, given that there are other things with higher priorities.
It's a little more complicated than simply not having enough time
(although that is certainly an issue). As I said earlier, getting on
the list for v1.2 doesn't mean that the core will commit to working on
a problem. It means that we're happy with the design that has been
proposed (or that any pending design decisions can be easily
resolved), and if a patch is ready in time it will get committed.
Although the feature discussion phase is the normal time for doing
design work, if a feature is big enough, it's reasonable to expect
that the design process may run on for a while. If that means that we
need to discuss the feature during time that would ordinarily be
'development phase', then so be it. The caveat on this is that
features that we have committed to will take priority, so you might
not always get immediate feedback.
Looking at #3591 in particular - another big part of the problem is
that the ticket tries to solve a theoretical problem that, in
practice, doesn't really exist - that of namespace collisions in
applications. I fully acknowledge that Django can't currently support
two applications with the same name - but my experience is that this
simply isn't an issue in practice. If you want to get support for the
ticket, part of your task is to convince someone in the core that it
is a common problem that needs to be fixed. (As a side note - if you
want to kickstart that design process now, feel free - but start a new
thread :-)
>> At this point, I would suggest that v1.3 is a more realistic goal -
>> with the advisory that you try to get the discussion going at the
>> _start_ of the discussion phase, not at the end.
>
> Perhaps not having been able to follow the list closely is my problem.
> I must have missed a signpost which said something like, "time to put
> our thinking caps on for 1.2" and only realised that the planning was
> under way when I saw Jacob's post of two days ago which does say,
>
> "We're still gathering feature requests for 1.2".
Those following the activity on django-dev for the last 6 months will
have noticed the change in stance - prior to v1.1 being released,
proposals were met with "wait until v1.1 is released"; after the
release, there has been a lot of discussion about the specifics of
particular features. This is also reflected in the traffic on the list
- there were 181 messages to django-dev in June, and 458 in September.
Again, this is something we could have advertised better.
> So I'm sorry I got the impression from that statement that we had more
> than just a few days to go. And I'm not sure that it matters anyway,
> as from what I can tell, it's not really a core dev priority and the
> main roadblock is lack of core dev time to discuss/guide around what
> are perceived as outstanding issues.
You missed the bit earlier in Jacob's message:
"We'll begin voting on features for 1.2 very soon (today or tomorrow)".
We are still open to new suggestions - Jacob's message was more of a
"last call". However, at this late stage, new proposals will need to
be essentially prêt-à-porter if they are going to be serious
candidates for consideration.
Yours
Russ Magee %-)
Vinay Sajip
On Oct 10, 12:51 pm, Russell Keith-Magee <freakboy3...@gmail.com>
wrote:
> It isn't just a matter of core developers not having enough time to
> review a specific patch - it's that there is a lot more design work
> required.
> That design discussion needs to happen before we know if we're going
> to be in a position to commit code. For example, if the only way to
> implement the feature well is to introduce major backwards
> incompatibilities in the way applications are loaded, we may need to
> defer the implementation until v2.0 when we are in a position to break
> backwards compatibility.
the feature. I'm willing to commit time and effort to it, but not
without *some* involvement from a committer. The changes for this will
get into different parts of Django, and so a design review is not
something that can be done quickly. And if it's not a priority for the
core devs, then why should they spend what is potentially a fair bit
of time on something they don't much care about? I respect that, and
likewise don't see much sense in committing my time and effort unless
it's mutually agreed to be worth spending the time on.
> I will admit that we (the core) haven't done a great job officially
> communicating 'state changes' like the start of the feature discussion
> phase. When you're in the middle of things, the need to put out blog
> posts etc isn't always apparent. This is something that we as a
> community (and the core team in particular) need to improve on.
>
> For the record, the Django release cycle is documented here:
>
> Given that almost 3 months has past since the release of v1.1, it's
> safe to assume that we're nearing the end of the proposal phase.
reasons, so I'm not complaining about anything.
> It's a little more complicated than simply not having enough time
> (although that is certainly an issue). As I said earlier, getting on
> the list for v1.2 doesn't mean that the core will commit to working on
> a problem. It means that we're happy with the design that has been
> proposed (or that any pending design decisions can be easily
> resolved), and if a patch is ready in time it will get committed.
with the design" unless some non-trivial time is spent on looking at
it. It's a bit chicken and egg ;-)
> Although the feature discussion phase is the normal time for doing
> design work, if a feature is big enough, it's reasonable to expect
> that the design process may run on for a while. If that means that we
> need to discuss the feature during time that would ordinarily be
> 'development phase', then so be it. The caveat on this is that
> features that we have committed to will take priority, so you might
> not always get immediate feedback.
the core devs risks being rejected because it isn't what they were
expecting and requires more time to think about than they are willing
to spend.
> Looking at #3591 in particular - another big part of the problem is
> that the ticket tries to solve a theoretical problem that, in
> practice, doesn't really exist - that of namespace collisions in
> applications. I fully acknowledge that Django can't currently support
> two applications with the same name - but my experience is that this
> simply isn't an issue in practice. If you want to get support for the
> ticket, part of your task is to convince someone in the core that it
> is a common problem that needs to be fixed. (As a side note - if you
> want to kickstart that design process now, feel free - but start a new
> thread :-)
problem for me when I started looking into it and made my patch, but
it isn't a problem for me any more. I do know that every now and again
a new person adds themselves to the cc: for the ticket, indicating
some interest in the outcome, but it's obviously not thousands or even
hundreds of people. However, it does remain a wart, in the face of all
that's been said about reusable apps.
> Those following the activity on django-dev for the last 6 months will
> have noticed the change in stance - prior to v1.1 being released,
> proposals were met with "wait until v1.1 is released"; after the
> release, there has been a lot of discussion about the specifics of
> particular features. This is also reflected in the traffic on the list
> - there were 181 messages to django-dev in June, and 458 in September.
> Again, this is something we could have advertised better.
to follow the list more closely in recent months.
> "We'll begin voting on features for 1.2 very soon (today or tomorrow)".
stations stay open :-)
> We are still open to new suggestions - Jacob's message was more of a
> "last call". However, at this late stage, new proposals will need to
> be essentially prêt-à-porter if they are going to be serious
> candidates for consideration.
I mean).
Thanks for the detailed response,
Vinay Sajip
Hanne Moa
<freakb...@gmail.com> wrote:
> Looking at #3591 in particular - another big part of the problem is
> that the ticket tries to solve a theoretical problem that, in
> practice, doesn't really exist - that of namespace collisions in
> applications.
That's funny, has happended three times to me this far. Not to mention
clashes with globally installed weirdo python libraries I didn't even
know existed before django broke. And it is quite the struggle to
figure out what is actually wrong when this happens. Relative imports
identical to absolute imports are Evil(tm). (Good incentive to always
use virtualenv everywhere though.)
Also, contentypes are less useful because its unicode() only shows the
model, not the app, I have several models with the same (class)name
from different sources... I always use db_table in my models too now
after being burned by clashes in the database.
The way to prevent such clashes is of course to *never* use reusable
apps directly but always fork, and in addition always use
virtualenv...
I can't wait 'till one has to prefix relative imports with dots as one
may in 2.6, even if the syntax *is* bug-ugly.
HM