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).
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.
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.
> On Thu, Jun 12, 2008 at 10:03 AM, Jacob Kaplan-Moss > <jacob.kaplanm...@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.
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.]
I like it, but mainly that's because I'm not the "maybe" list, and I'm sure I can get it done in time. I do have one suggestion, though.
On Wed, Jun 11, 2008 at 10:03 PM, Jacob Kaplan-Moss
<jacob.kaplanm...@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.
Jacob Kaplan-Moss wrote: > This is a call for comments on the proposed Django 1.0 roadmap and schedule.
> Note that though this is worded in the future perfect tense, it is only a draft; > I'm looking for feedback and comments from the community before the core > developers and I post a the final version of this document (which I will do > over the weekend).
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?
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. :)
On Wed, Jun 11, 2008 at 9:26 PM, Marty Alchin <gulop...@gamemusic.org> wrote: > I think I know what you mean here, but "dropped" sounds an awful lot > like an all or nothing deal: either it makes it into 1.0 or it never > makes it at all. It's probably best to clarify that "dropped" just > means "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.
On Wed, Jun 11, 2008 at 9:23 PM, Jacob Kaplan-Moss
<jacob.kaplanm...@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."
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.
Jacob Kaplan-Moss wrote: > This is a call for comments on the proposed Django 1.0 roadmap and schedule.
> Note that though this is worded in the future perfect tense, it is only a draft; > I'm looking for feedback and comments from the community before the core > developers and I post a the final 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.
> 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.
> 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.
On Wed, Jun 11, 2008 at 9:46 PM, Karen Tracey <kmtra...@gmail.com> wrote: > One thing I don't see mentioned anywhere is defect #6755 "Model Inheritance > doesn't work in the admin" (whereas GenericForeignKey admin support is > specifically called out). I don't know if #6755 is classified as must 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.
On Wed, Jun 11, 2008 at 9:27 PM, Jeff Anderson <jeffe...@programmerq.net> wrote: > I'm curious: is there a reason that the milestone feature was disabled on > the trac page? > Would it be good/beneficial to put these "must-haves" in a 1.0 milestone, > and (some of) the "No" features in a 1.1 milestone?
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.
Seems like a very good roadmap, and it must clear a lot of concern and
uncertainty some people may have.
In the must-have features, or at least in the maybes, I'd put the bugs
introduced by, or not properly fixed by, the merge of the queryset-
refactor branch. A list of related open tickets has been given in [1].
> > 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.
On Wed, Jun 11, 2008 at 9:56 PM, Julien <jpha...@gmail.com> wrote: > In the must-have features, or at least in the maybes, I'd put the bugs > introduced by, or not properly fixed by, the merge of the queryset- > refactor branch. A list of related open tickets has been given in [1].
That list seems perfect to me. I'll be around in San Francisco to
help on the sprint, so if #6095 isn't merged by then I can focus on
whatever needs to be done to get it to where it needs to be.
> On Wed, Jun 11, 2008 at 9:46 PM, Karen Tracey <kmtra...@gmail.com> wrote: >> One thing I don't see mentioned anywhere is defect #6755 "Model Inheritance >> doesn't work in the admin" (whereas GenericForeignKey admin support is >> specifically called out). I don't know if #6755 is classified as must 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.
> On Thu, Jun 12, 2008 at 10:54 AM, Jacob Kaplan-Moss > <jacob.kaplanm...@gmail.com> wrote:
> > On Wed, Jun 11, 2008 at 9:46 PM, Karen Tracey <kmtra...@gmail.com> > wrote: > >> One thing I don't see mentioned anywhere is defect #6755 "Model > Inheritance > >> doesn't work in the admin" (whereas GenericForeignKey admin support is > >> specifically called out). I don't know if #6755 is classified as must > 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.
> I've just updated the ticket to reflect this.
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.
> This is a call for comments on the proposed Django 1.0 roadmap and schedule.
[snip]
> Must-have features
I love that this list is small and concentrated. This is exactly what
is needed in order to get a release out quickly and focus development
effort.
+1 from me.
> "Maybe" features
These 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.
I have to ask why must Django prevent work in this regard? Surely you
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.
I think a goal of bug-free is admirable but not practical. Debian
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.
On Wed, Jun 11, 2008 at 11:17 PM, metaj...@gmail.com <metaj...@gmail.com> wrote: > I have to ask why must Django prevent work in this regard?
To be perfectly fair, it's not really "prevented". Django supports the use of database backends not defined in Django itself, so third-party development of 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).
-- "Bureaucrat Conrad, you are technically correct -- the best kind of correct."
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...
Jacob Kaplan-Moss wrote: > Django 1.0 will be released in early September.
Ouch... To paraphrase Joel Spolsky "If you have a hand-wavy feature called "1.0 release" and you schedule 3 months for it, you are doomed". Jacob, honestly, where this date has come from? It can as easily be August or 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.
Wow, I'd say this is a pretty good schedule, Jacob.
> So we'd like to deal with that situation a bit specially. I've > unfortunately not > had a chance to ask Thejaswi (the student working on comments) or > Jannis (his > mentor) about this, so obviously they'll need to be OK with the idea.
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.
