RFC: Django 1.0 roadmap and timeline
Jacob Kaplan-Moss
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 I will do
over the weekend).
What's will be in 1.0?
======================
The primary reason we've not yet released 1.0 is the long feature
wish-list. We need to balance this list of features against the need
for a timly release and speedy process. To that end, we'll categorize
all the features of 1.0 thusly:
* 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.
This of course means that these features are the "A" features, and we'll
ask anyone who can help to focus on these features *first*.
* "Maybe" features: things that *should* be in 1.0 and should be worked on
in the run up to the release. If, however, features on this list aren't
completed, they will be dropped.
* "No" features: things that specifically will *not* be in 1.0, and which
we'll ask developers not to focus on. We need to trim down to hit dates,
after all.
Must-have features
------------------
1. ``newforms-admin``.
It's clear from discussion on this list that most consider a release without
``newforms-admin`` to be a bad idea. Further, ``newforms-admin`` is nearly
done; we've already started talking about merging it to trunk.
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 views, and in
``django.contrib.auth``
``django.contrib.comments`` still uses ``oldforms`` as well, but there's
special situation here; see below.
3. Making Django 100% WSGI compliant.
This simply involves fixing ticket #285. We've delayed doing this to avoid
the backwards-incompatible change, but we must make this change before 1.0.
"Maybe" features
----------------
Again, these are features that *should* be in 1.0. In most cases, they're
actively being worked on by members of the development community and simply need
focus by committers (more about how that process will work below).
These features are arranged in *rough* order of importance.
1. Signal performance improvements (#6814).
2. Large file uploads (#2070).
3. ``INSTALLED_APPS`` refactoring (i.e. ``app()`` objects) (#3591).
4. File storage refactoring (#5361).
5. Model-level validation (#6845).
6. Full ``GenericForeignKey`` support in newforms-admin (#4667).
7. Land GeoDjango as ``django.contrib.gis``.
8. Many-to-many intermediates (#6905).
9. Fix all known bugs preventing Django from running on alternate Python
implementations. In practice this means fixing any bugs filed before 1.0 beta
from people working on running Django on an alternate VM.
10. De-cruftify custom template tag loading (including removing custom template
tag ``__path__`` hacking) (#6587, etc.).
11. Better support for controlling middleware ordering (#3591).
12. Syntax for self-referencing fields in queries (#7210).
13. Finish documentation refactoring.
Features not in 1.0
-------------------
Unfortunately, the only way to get this done is to say no a lot. Let's start
now:
1. Aggregation support. Although this is a Summer of Code project that's looking
*very* promising, the timeline for SoC won't fit with the aggressive schedule
we're setting for 1.0. Further, it's a "dangerous" change in that it modifies
parts of Django's query engine, and that needs to be rock-solid for a 1.0
release.
The good news is that it'll make a kick-ass 1.1 feature!
2. Any other additions to ``django.contrib``. Though there are many nice
candidates out there, we simply don't have time to roll them into Django
in time for a release. We'll come up with a "contrib process" post-1.0
and start looking at this then.
3. Any additional database backends. Again, the overhead in integrating a new
database backend is too much. These will need to remain external backends
until after 1.0.
4. Any features not on this list.
We want to ship bug-free, so we'll dedicate as much of our time to bug
stomping as possible. This means that feature requests will need to be
deferred.
Schedule
========
Django 1.0 will be released in early September.
The general release process will be:
* 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.
The alpha release will also promote any "pending deprecation" warnings to
full-blown deprecation warnings.
* 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 --release candidate. The candidate
release will mark a total freeze (as well as a string freeze for
translators); only outright bug fixes will be accepted past this point.
* A final release.
* A big fucking party.
We will hold development sprints in between each release to focus on the next
release.
Dates
-----
July 10-12 ``newforms-admin`` sprint in person at EuroPython and around
the world in IRC.
July 18 or 19 Push to 1.0 alpha sprint in the San Francisco area, and in IRC.
July 20 **1.0 alpha.**
August 1 or 2 Push to beta sprint in Lawrence, and etc.
August 5 **1.0 beta 1.**
August 8/9 Push to beta 2 sprint, location TBA.
August 12 **1.0 beta 2.**
August 15/16 Release candidate sprint, location TBA.
August 19 **1.0 rc 1.**
August 22/23 Final release sprint, location TBA.
August 26 Earliest possible 1.0 release date, or perhaps rc2.
September 2 **1.0**
All the releases until 1.0 will be "snapshot" releases: we won't be backporting
fixes -- even security fixes -- but will just be fixing bugs in the next
release.
Process
=======
Each feature on the list (both "must-have" and "maybe") gets a "lieutenant" (to
steal of term from the Linux community) and a committer assigned. It's OK if
this is the same person, but the idea is that one committer can keep an eye and
commit from patches from a number of trusted lieutenants. In most cases, the
features on the todo list have obvious lieutenants; we'll need to assign missing
ones and also committers. I'll start putting together this list tonight; right
now it's mostly in my head.
James, as the release manager, will be in charge of keeping the schedule. He'll
keep track of who's working on what issues so that bug reports can be
efficiently routed; he'll also nag, cajole and (if necessary) berate developers
who are in danger of missing deadlines.
Once 1.0 is out we'll appoint a "version manager" (thanks for the idea, Rob).
This person will be responsible for maintaining the 1.0 release series, which
means backporting security fixes and "important" bugs and releasing 1.0.1, etc.
Similarly, as soon as we have a volunteer we'll appoint a 0.96 version manger
who will do the same with 0.96. We'll continue to support 0.96 until 1.1 ships.
With the 1.0 release, however, we will stop support 0.95 and earlier. This is
somewhat flexible; if someone has a stake in one of those older versions we'll
happily let them continue to maintain those releases, but if nobody steps up the
core team won't be able to do it.
--------------------------------------------
Comments are, of course, highly welcome. Fire away.
Jacob
Russell Keith-Magee
<jacob.ka...@gmail.com> 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 %-)
Jacob Kaplan-Moss
You are not blind; I, however, have mad wicked copy-paste skillz. Ahem.
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 the comment
system -- not just replacing forms -- is overdue, and is the subject of a Summer
of Code project.
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. But,
assuming this works, I'd like to do the following:
August 11 is the suggested pencils down date for GSOC. This means that if
Thejaswi is on track, he will be completed around the time of the beta 2 freeze
date. July 14 is the midterm evaluation date for Summer of Code; we should be
able to get a good idea then whether completion on schedule is likely.
If the midterm evaluation says that the project is going badly, we abandon ship
and paper over the problem by simply replacing the form components with
newforms.
If the midterm evaluation is positive -- which I expect it to be -- we work on
the assumption that it will be merged around beta 2 (or earlier, if Thejaswi has
something ready). We encourage people to push newforms-comments pretty hard,
especially during sprints.
If we get to August 11 and we don't have a newforms-comments release candidate,
we can simply release with oldforms comments: it'll be annoying but not a
deal-breaker.
This does mean newforms-comments will be a late feature to the trunk (although
only 3 weeks after the feature cutoff for other features), but if we encourage
testing in its own branch, we should be able to mitigate the risk. I would also
hope that the last 3 weeks of GSOC development would be mostly bugfixing anyway,
rather than substantial changes.
[With thanks to Russ -- the idea's originally his, and most of the
above is coppied out of something he wrote yesterday.]
Jacob
Marty Alchin
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
<jacob.ka...@gmail.com> wrote:
> * "Maybe" features: things that *should* be in 1.0 and should be worked on
> in the run up to the release. If, however, features on this list aren't
> completed, they will be dropped.
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 "dropped from 1.0, to be added in the next release after it's
completed." Yeah, it might be obvious to some of us, but a lot of
people could read it the wrong way.
-Gul
Jeff Anderson
> 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 I will do
> over the weekend).
>
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?
One of the first things I looked for when I got interested in Django 1.0
was look for the milestone page in trac. I know that there are similar
things in the wiki page, but the status on several of the tickets listed
seem to be stale.
Hopefully my curiosity represents curiosity of others, and I am doing
what I can to push along 1.0, although I'm still getting up to speed on
the development process. :)
Cheers!
Jeff Anderson
Jacob Kaplan-Moss
> 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 "dropped from 1.0, to be added in the next release after it's
> completed."
Indeed. I expect that anything on that list that doesn't make it into
1.0 will be in 1.1.
Jacob
James Bennett
<jacob.ka...@gmail.com> wrote:
> This does mean newforms-comments will be a late feature to the trunk (although
> only 3 weeks after the feature cutoff for other features), but if we encourage
> testing in its own branch, we should be able to mitigate the risk. I would also
> hope that the last 3 weeks of GSOC development would be mostly bugfixing anyway,
> rather than substantial changes.
Also, it's worth noting that because contrib.comments is an
application rather than a core part of Django, it will be easy to keep
it available for those who want to stick to it, and if someone in the
community wants to offer continuing support for it I wouldn't be
averse to letting them do so (though of course django.oldforms will
eventually disappear, at which point any third-party maintenance
effort will probably need to do some porting).
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
Brian Rosner
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 views, and in
> ``django.contrib.auth``
Just wanted to point out that the newforms-admin branch has already
ported django.contrib.auth to newforms.
> * A big fucking party.
A *really* big fucking party ;)
Brian Rosner
http://oebfare.com
Eugene Lazutkin
matches my expectations. +1.
Thanks,
Eugene
Karen Tracey
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 1.0 should rely on the deprecated ``oldforms`` package.
We'll need to replace ``oldforms`` usage in generic views, and in
``django.contrib.auth``
The django.contrib.auth case has already been done in the newforms-admin branch, so don't anybody run out and starting working on it for trunk.
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 have for newforms-admin to land (it's not even specifying newforms-admin as the release anymore), or in the "maybe" category? It's gotten a fair amount of interest from people who have started using inheritance so it would be nice to have its status be specified.
Karen
Jacob Kaplan-Moss
> 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 have
> for newforms-admin to land (it's not even specifying newforms-admin as the
> release anymore), or in the "maybe" category? It's gotten a fair amount of
> interest from people who have started using inheritance so it would be nice
> to have its status be specified.
I'd say it's pretty important and should be considered part of the
todo list for newforms-admin. However, since MI doesn't work in the
old admin, either, there's no reason that it particularly has to be
done before or after landing NFA on trunk.
Jacob
Jacob Kaplan-Moss
> 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?
Probably because we haven't really needed the feature until now :)
I'll make some milestones; we can add tickets to them as we go.
Jacob
Julien
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 been given in [1].
Thanks again for clarifying the roadmap to 1.0.
[1]
http://groups.google.com/group/django-developers/browse_thread/thread/43e025656481cfe6/a8c0feaf7f76cddd?lnk=gst&q=queryset+django+releases#a8c0feaf7f76cddd
On Jun 12, 12:46 pm, "Karen Tracey" <kmtra...@gmail.com> wrote:
> On Wed, Jun 11, 2008 at 10:03 PM, Jacob Kaplan-Moss <
>
George Vilches
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
Jacob Kaplan-Moss
> 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 is at
http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&keywords=%7Eqsrf-cleanup&order=priority.
This falls under "fix outstanding bugs"; if at all possible we should
ship 1.0 with zarro known boogs.
Jacob
Jacob Kaplan-Moss
>> 8. Many-to-many intermediates (#6905).
>>
> Shouldn't that be #6095? http://code.djangoproject.com/ticket/6095
Yup; thanks.
Jacob
flo...@gmail.com
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
Russell Keith-Magee
I've just updated the ticket to reflect this.
Russ %-)
Karen Tracey
You marked it nfa-blocker, which doesn't match my understanding of the meaning of that tag and what Jacob said. nfa-blocker I thought meant something that has to be fixed before a merge to trunk, but this is not in that class.
With the focus on 1.0 now, the two (main) tags that have been in use on newforms-admin are missing a category, perhaps. There's nfa-blocker for stuff that has to be done before merge to trunk and nfa-someday for everything else. That doesn't given any way to specify the middle ground of after trunk merge but before 1.0. Actually there's nothing newforms-admin specific about this problem, people will be wanting to know what tickets are considered essential for 1.0 and I don't know what mechanism will be used to track that in general?
If the meaning of nfa-blocker is now going to be broader than "essential for merge to trunk" than that should be spelled out, and existing defects perhaps reclassified...there may be some in nfa-someday that really should be nfa-blocker if that now means "before 1.0". Personally I'd prefer not changing the meaning and just including the newforms-admin tickets in whatever sweep is done (I'm assuming a ticket sweep will be needed to figure out which are the essential must-fix tickets for 1.0) of tickets in general to classify them as pre- or post-1.0 concerns.
Karen
meta...@gmail.com
> 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 all seem reasonable. Certainly anything important to me on this
list is worth me making sure it gets done. #2070 is one that we deal
with a lot. It's not that I need support for "large" files, but if
someone accidentally does upload a large file, it can take out the
server. So for me this isn't as much about large file support as
preventing downtime due to silly users.
> Features not in 1.0
You have to draw the line somewhere, of course.
> 3. Any additional database backends. Again, the overhead in integrating a new
> database backend is too much. These will need to remain external backends
> until after 1.0.
could allow work to continue but somehow label it experimental? I'm
thinking of Python's way of dealing with this in particular: from
__future__ import blah. I don't see why integrating a new backend
places any workload on any other part of Django. Let those willing
hackers attempt to make something experimental for the release. This
will help them get feedback from early adopters and encourage people
who need the support to seek it out and discuss.
> We want to ship bug-free, so we'll dedicate as much of our time to bug
> stomping as possible. This means that feature requests will need to be
> deferred.
runs into this problem all the time, and their releases are delayed
for years because of it. Certainly Django is not as complex, but I
think that doing the best we can to sprint out all the bugs possible
is the best solution. If it turns out that you missed something,
well, that's what point releases are for.
[snip the schedule]
The schedule looks good. I think you should be hardlined about the
dates and not as hardlined on what makes it in. No one expects an
alpha to be production ready, so if you have to merge newforms-admin a
little earlier than you would like, just do it and fix the bugs before
the next alpha.
If the schedule must slip, I suggest adding a another release rather
than delaying one. Ie, let the number of alphas or betas be variable,
but keep up the schedule of releases every week.
I will commit to having several of my team participate in one of the
sprints (barring death or natural disaster, etc) leading up to the
release. We're building new stuff with Django, and we have old stuff
on Django, and in general we depend on Django to get things done. I
just *hate* having to maintain a private fork of 0.96.
[lack of support for 0.95 and older]
I would even consider dropping all but security patches to 0.96. That
is practically the limit of support anyway it seems, and is not likely
to cause much work. Those of us on 0.96 don't expect you to support
our private branches anyway, and maintaining that mess ourselves is a
huge incentive to bite the bullet and upgrade. You also might
consider letting whoever can spare the time apply patches to 0.96 and
do point releases for those people who will stay there forever (and
I'm sure there will be plenty). You lose nothing as long as there are
volunteers willing to do that work.
jack.
PS. I'm glad at least some of you thought my criticism today
constructive. These are hard things to get right, and I've certainly
made the same mistakes on previous projects. I took me _years_ to get
Ogg Vorbis 1.0 out the door, and I still deeply regret some of the
release decisions we made there. Live and learn.
James Bennett
> 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 for the one most people
mention wanting -- MS SQL -- I think that's a good idea; that backend
has a history of people stepping up, putting in a burst of work and
then fading away, leaving the code dead and the Django dev team
responsible for maintaining it as long as it's in Django's codebase.
What really needs to happen there is much the same as what happened
with Oracle: some people who are really clamoring for it need to
organize and start pooling their efforts to develop something that can
comfortably become a part of Django (and now that external backends
are supported and qs-rf made the underlying mechanics of custom Query
classes much simpler, anyone wanting to do a new backend probably
faces a much easier time of it than the Oracle folks did).
Post-1.0, any externally-maintained backend that has a good track
record of support and a commitment from a developer to maintain it
into the future can easily be considered for integration, but until
then such projects should stay external.
> I would even consider dropping all but security patches to 0.96. That
> is practically the limit of support anyway it seems, and is not likely
> to cause much work. Those of us on 0.96 don't expect you to support
> our private branches anyway, and maintaining that mess ourselves is a
> huge incentive to bite the bullet and upgrade. You also might
> consider letting whoever can spare the time apply patches to 0.96 and
> do point releases for those people who will stay there forever (and
> I'm sure there will be plenty). You lose nothing as long as there are
> volunteers willing to do that work.
Personally, so long as folks are OK with the fact that it'll only ever
get security fixes I'd be happy with setting a time-based official
support window for 0.96, after which a community effort can pick it up
if desired. At that point I'd imagine it wouldn't be too hard to set
up one or two folks with commit access to the 0.96-bugfixes branch for
that purpose (and we've had good experience with clients who are on
legacy 0.91 Django installs and quite happily just run off a
0.91-bugfixes checkout, which makes pushing security updates to them
insanely easy).
Gábor Farkas
<jacob.ka...@gmail.com> 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 content, you have to hack around
and create a form for it, etc...
as far as i understand, this change is a backwards-incompatible change,
and also touches quite the basic parts of the whole
models/forms/validation system,
and i thought it's in the plan to have this in 1.0.....
so i wonder, that if the WSGI-conformance ticket is a must-have, then
why this isn't too...
perhaps the WSGI-change is smaller...
anyway, would be great to have the how-can-we-help data
(liutenant/committer/etc)
published as soon as possible...
gabor
Rajeev J Sebastian
On Thu, Jun 12, 2008 at 5:03 AM, Jacob Kaplan-Moss
<jacob.ka...@gmail.com> 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 Sebastian
Ivan Sagalaev
> 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 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.
I was refraining from saying this because it's not that important after
all. However since Simon had (and others will) announce this date all
over the internet, we as a community will feel obliged to meet it
somehow, e.g. by throwing out really important things that we don't want
to. So may be it's not too late to state clearly that we have a plan but
it's not a schedule.
Jannis Leidel
> 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.
I can only answer this preliminarily at the moment due to Thejaswi's
absence this week. But I'm confident of his progress and personally
think we can meet the schedule.
> We encourage people to push newforms-comments pretty hard,
> especially during sprints.
Good idea.
Cheers,
Jannis
Forest Bond
On Jun 11, 10:03 pm, "Jacob Kaplan-Moss" <jacob.kaplanm...@gmail.com>
wrote:
> release. That is, if the work on this list is not completed by a
> release date, we'll push the date.
#285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
Incidentally, so did Adrian. The text is copied from his post with
subject "Django 1.0 features -- the definitive list".
http://groups.google.com/group/django-developers/browse_thread/thread/b4c237ad76f9eeca
It's in important change and is backwards-incompatible.
Thanks,
Forest
Ville Säävuori
> 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.
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.
As what would those dates exactly be, I couldn't care less. As long as
they're not too far in the future, lets jazz on! :)
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.
- VS
Nick
> 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.
months. Hopefully, this will reassure the worriers, as well as giving
everyone a real target to aim for.
The fact that a roadmap exists is the important thing, more than the
particular dates that have been chosen. Early September does
sound ambitious, but if there is a good level of participation in the
sprints, and if the output from those sprints can be reviewed and
checked in efficiently enough, it should be achievable.
I missed the last sprint and haven't contributed any patches for a
while now, but I'm certainly going to try and do my bit to get 1.0 out
the door...
N.
Marty Alchin
> 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
Luke Plant
> 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,
Luke
--
"Don't mention it. Oh, you didn't." (Marvin the paranoid android)
Luke Plant || http://lukeplant.me.uk/
Ivan Sagalaev
> 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 vital (for which I'm not a great judge) then it can only
happen by actually calculating the date, not just by choosing something
"motivating". And calculating means that every feature should be divided
into pieces that are fully designed and scheduled. It's very hard and,
you know, *boring* and it's why I think nobody will do this (I wouldn't
:-) ). So what's the point of hoping for September if it's not real?
Remco Wendt
On Jun 12, 4:03 am, "Jacob Kaplan-Moss" <jacob.kaplanm...@gmail.com>
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.
release thing?
From the must haves list it is mainly clearing the new-forms admin
blockers list. So if alpha is a (soft) API freeze, do the newforms-
admin people think we can work away all those tickets before july
20th?
Also I it may be interesting to show some love to the sprintideas page
(http://code.djangoproject.com/wiki/SprintIdeas). And get a wiki page
up for the Europython sprint (I couldn't find it). If you want me to
take care of this stuff, let me know.
Remco
Jacob Kaplan-Moss
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 the idea is that if someone comes along
wanting to help, we can show them a todo list of features that'll
actually help us hit 1.0 on schedule.
If people are excited about other database backends they of *course*
can work on them, but we'll simply defer discussion of including the
backend in Django until after 1.0 ships. I'm OK doing this since
database backends can be external (i.e.
http://code.google.com/p/django-mssql/).
> 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.
> I would even consider dropping all but security patches to 0.96. That
> is practically the limit of support anyway it seems, and is not likely
> to cause much work.
Good thoughts, but let's table this discussion until we actually get
around to appointing version managers; if we try to tackle too much
process now my head asplode.
Jacob
Jacob Kaplan-Moss
<man...@softwaremaniacs.org> 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 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.
Remember back in math class where you'd get marked down despite the
correct answer because you didn't "show your work"? I always hated
that. Still do, apparently, because although I just threw those dates
out there, I really did work very hard on them, and I do think they're
feasible.
First, it's not "a had-wavy feature": only the blocker items *must* be
done for 1.0. So if we'll all extremely lazy, we've got one
big-but-mostly-done feature (nfa), one medium-but-easy-and-also-almost
done feature (newforms in generic views), and one
trivial-and-done-but-not-merged feature (#285). I think it's perfectly
reasonable to expect to get those done in three months, don't you?
I didn't, though, just plunk a date three months out; the idea is to
take about a month to get to the alpha -- that is, one month to finish
the blocker features (but not necessarily make them bug-free), then
two weeks to the first beta, then a week each between each snapshot
until 1.0.
Further, I actually *can* predict at least one person's time in "work
hours": mine. Thanks to my kick-ass job, I get to spend most of my
work hours on Django. On top of that, I have firm commitments to
attend the sprints from a number of talented developers; I know from
experience that sprints are incredibly productive. We'll have *six* of
them between now and September.
Now, of course only time will tell whether I'm nuts or not, but I'm
pretty confidant that we can hit these dates. More important, though,
is that having firm dates will force the people working on "maybe"
features to put up or shut up, and it'll make our jobs as integrators
much easier -- only having a handful of things to merge will make that
process *much* less fraught.
> So may be it's not too late to state clearly that we have a plan but
> it's not a schedule.
Well, I tried to do that with the disclaimer about this being a draft
at the top. But, yeah, of course this is just a draft. That said, I
don't hear alternate timeline proposals -- do you have one? If you do,
you might want to learn from my mistake and "show your work" :)
Jacob
Jacob Kaplan-Moss
> 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 figure out
something to do on #749 as well. Added to the todo list.
Jacob
Jacob Kaplan-Moss
>
>> 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 to wrap it up.
However, while it would suck to ship 1.0 without it, there's nothing
about the API that has to be backwards-incompatible, and it's a
potentially "dangerous" feature in that it could spawn a lot of work.
So, if we can get there, great; if not, well, you've got a reason to
look forward to 1.1 :)
> so i wonder, that if the WSGI-conformance ticket is a must-have, then
> why this isn't too...
>
> perhaps the WSGI-change is smaller...
Exactly -- the WSGI change is very small, and actually done (see the
latest patch on #295). It basically just needs to be applied.
> anyway, would be great to have the how-can-we-help data
> (liutenant/committer/etc)
> published as soon as possible...
Yup, that's the next step!
Jacob
Jacob Kaplan-Moss
> 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
might need to tweak the APIs to fix bugs afterwards. I'd say that best
plan should be that any backwards-incompatible API changes after beta
1 need a quick discussion here; sound good?
> Also I it may be interesting to show some love to the sprintideas page
> (http://code.djangoproject.com/wiki/SprintIdeas). And get a wiki page
> up for the Europython sprint (I couldn't find it). If you want me to
> take care of this stuff, let me know.
That would be awesome -- thanks!
Jacob
meta...@gmail.com
>
> 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.
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 somewhere than to get it for a project on Google Code.
> And for the one most people
> mention wanting -- MS SQL -- I think that's a good idea; that backend
> has a history of people stepping up, putting in a burst of work and
> then fading away, leaving the code dead and the Django dev team
> responsible for maintaining it as long as it's in Django's codebase.
code in the repository. Surely it is quite easy to not include MS SQL
in the default list of backends and/or mention in the documentation
that MS SQL support is unsupported and experimental until such time as
it improves. Plenty of projects have bits of code that are crufty and
get labeled as such, and don't burn cycles maintaining it themselves.
To give a concrete example, the Xiph.org repositories have several
experimental codecs that are completely abandoned (unless someone
shows up to hack on them). We leave them there because they show
people that we foster creativity and community contribution, and there
are many good ideas there that should be kept around for reference.
And who knows, someday the guy who worte most of the Tarkin code may
come back and give MPEG-4 video a run for its money. But he certainly
won't if we just throw out his code. Communities are inclusive.
> What really needs to happen there is much the same as what happened
> with Oracle: some people who are really clamoring for it need to
> organize and start pooling their efforts to develop something that can
> comfortably become a part of Django (and now that external backends
> are supported and qs-rf made the underlying mechanics of custom Query
> classes much simpler, anyone wanting to do a new backend probably
> faces a much easier time of it than the Oracle folks did).
maintainer. By forcing the project outside the codebase, you've
eliminated (almost) the possibility of a bunch of random people
helping a little bit and getting the code in shape. It may be that
there won't be some dedicated single person who is willing to champion
this. But I bet there are a lot of people who are willing to help.
If you search on MS SQL support and Django, you find people talking
about how it doesn't work because of pagination problems. If you
search on RoR and MS SQL support, people are talking about the best
ways to do replication. It would be good for the project to attract
the poor developers using MS SQL (not by choice in many case) who work
at corporations and academia. I know people at the University of New
Mexico who would love to use Django, but the only requirement it must
fulfill is MS SQL support. Neither they nor I have the time to invest
to make MS SQL support happen, but removing MS SQL support from the
repository makes them think Django doesn't. When it was not working
so great, but still included, at least they had hope that by the time
they were ready someone would have fixed it.
jack.
Remco Wendt
On Jun 12, 4:43 pm, "Jacob Kaplan-Moss" <