Changes between Initial Version and Version 1 of VersionOneRoadmap

Timestamp:

Jun 16, 2008, 9:42:55 AM (17 years ago)

Author:

Jacob

Comment:

--

VersionOneRoadmap

@@ +1 @@
+{{{
+#!rst
+
+===============================
+Django 1.0 Roadmap and Schedule
+===============================
+
+This document details the schedule and roadmap towards Django 1.0. All the details are below, but here's the executive summary:
+
+    * Django 1.0 will be released in `early September`__
+    
+    * To meet that deadline, Django 1.0 has a minimal set of `must-have
+      features`_. The big feature on that list is ``newforms-admin``.
+      
+    * There's a larger set of `"maybe" features`_: if these features are done
+      by the 1.0 feature-freeze date (August 5), they'll be included in 1.0.
+      
+    * Those who want to help out should read the rest of the document, and
+      especially `how you can help`_.
+    
+__ `dates`_
+
+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 timely 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
+   is a bit of a `special case`__.
+   
+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.
+
+__ `on comments`_
+
+"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 (#6095).
+
+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 (#730, #749).
+
+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-ass party.
+    
+We will hold development sprints in between each release to focus on the next
+release. 
+
+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.
+
+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**
+==============  ===============================================================
+
+See below_ for details about why these particular dates were chosen.
+
+.. _below: `XXX`
+
+Process
+=======
+
+Each feature on the list (both "must-have" and "maybe") will have 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. See :wiki:VersionOneFeatures for the current list of
+lieutenants and committers.
+
+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". 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, 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.
+
+How you can help
+----------------
+
+The only way we'll meet this deadline is with a great deal of community effort.
+To that end, here's how you can help:
+
+    * Read the `guide to contributing to Django`__. 
+      
+      This guide explains how our process works. where to ask questions, etc.
+      It'll save everyone time if we're all on the same page when it comes to
+      process.
+      
+    * Work from the list above.
+    
+      Get in touch with the lieutenant/committer for the feature you'd like
+      to work on and help out. Or just find open tickets and start submitting
+      patches!
+    
+      The joy of Open Source is that nobody gets to tell you what to do; you
+      can scratch whichever itch you like. However, if you work on items *not*
+      on the list of 1.0 features, you should expect that your patch won't get
+      checked in until after 1.0.
+      
+    * Attend a sprint (in person or in IRC).
+    
+      We'll have about a half dozen sprints between now and the final 1.0
+      release. Lots of work gets done at sprints, and there's usually someone
+      around willing to help new developers get started.
+      
+    * Test the release snapshots (alphas, betas) against your code and report
+      bugs.
+      
+      We need *lots* of testers if we're to have a bug-free release. Download
+      a snapshot or an SVN checkout and give it a try!
+      
+__ http://www.djangoproject.com/documentation/contributing/
+
+Notes and miscellany
+====================
+
+On comments
+-----------
+
+``django.contrib.comments`` is a bit of special case. Ideally, Django 1.0 will
+ship with *no* core use of oldforms. However, refactoring the entire comment
+system -- not just replacing forms -- is overdue, and is the subject of a Google
+Summer of Code project. So it would be silly to simply replace the form use when
+the whole package is scheduled to be replaced.
+
+August 11 is the suggested pencils down date for GSoC. This means that if
+Thejaswi (the student working on comments for GSoC) 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'll abandon
+ship and simply replace the form components in the current ``contrib.comments``
+with newforms; we'll ship the new comment library in a future release.
+
+If the midterm evaluation is positive -- which is highly likely -- we'll work on
+the assumption that the new comment framework will be merged intro trunk before
+the beta 2 release (and possible earlier, if Thejaswi has something ready).
+We'll encourage people to push the new framework pretty hard, especially during
+sprints.
+
+If we get to August 11 and we don't have a release candidate, we can simply
+release with oldforms comments: it'll be annoying but not a deal-breaker.
+
+}}}