[Numpy-svn] r6503 - trunk/doc/release
numpy-svn at scipy.org
numpy-svn at scipy.org
Fri Feb 27 02:23:08 EST 2009
Author: cdavid
Date: 2009-02-27 01:23:01 -0600 (Fri, 27 Feb 2009)
New Revision: 6503
Added:
trunk/doc/release/time_based_proposal.rst
Removed:
trunk/doc/release/time_based_proposal.txt
Log:
Rename the time-based proposal such as it is recognized as REST by trac.
Copied: trunk/doc/release/time_based_proposal.rst (from rev 6502, trunk/doc/release/time_based_proposal.txt)
===================================================================
--- trunk/doc/release/time_based_proposal.txt 2009-02-27 07:21:23 UTC (rev 6502)
+++ trunk/doc/release/time_based_proposal.rst 2009-02-27 07:23:01 UTC (rev 6503)
@@ -0,0 +1,106 @@
+.. vim:syntax=rst
+
+Introduction
+============
+
+This document proposes some enhancements for numpy and scipy releases.
+Successive numpy and scipy releases are too far appart from a time point of
+view - some people who are in the numpy release team feel that it cannot
+improve without a bit more formal release process. The main proposal is to
+follow a time-based release, with expected dates for code freeze, beta and rc.
+The goal is two folds: make release more predictible, and move the code forward.
+
+Rationale
+=========
+
+Right now, the release process of numpy is relatively organic. When some
+features are there, we may decide to make a new release. Because there is not
+fixed schedule, people don't really know when new features and bug fixes will
+go into a release. More significantly, having an expected release schedule
+helps to *coordinate* efforts: at the beginning of a cycle, everybody can jump
+in and put new code, even break things if needed. But after some point, only
+bug fixes are accepted: this makes beta and RC releases much easier; calming
+things down toward the release date helps focusing on bugs and regressions
+
+Proposal
+========
+
+Time schedule
+-------------
+
+The proposed schedule is to release numpy every 3 months - the exact period can
+be tweaked if it ends up not working as expected. There will be several stages
+for the cycle:
+
+ * Development: anything can happen (by anything, we mean as currently
+ done). The focus is on new features, refactoring, etc...
+ * Beta: no new features. No bug fixing which requires heavy changes.
+ regression fixes which appear on supported platforms and were not
+ caught earlier.
+ * Polish/RC: only docstring changes and blocker regressions are allowed.
+
+The schedule would be as follows:
+
+ +------+-----------------+-----------------+------------------+
+ | Week | 1.3.0 | 1.4.0 | Release time |
+ +======+=================+=================+==================+
+ | 1 | Development | - | |
+ | 2 | Development | - | |
+ | 3 | Development | - | |
+ | 4 | Development | - | |
+ | 5 | Development | - | |
+ | 6 | Development | - | |
+ | 7 | Beta | - | |
+ | 8 | Beta | - | |
+ | 9 | Beta | - | 1.3.0 released |
+ | 10 | Polish | Development | |
+ | 11 | Polish | Development | |
+ | 12 | Polish | Development | |
+ | 13 | Polish | Development | |
+ | 14 | | Development | |
+ | 15 | | Development | |
+ | 16 | | Beta | |
+ | 17 | | Beta | |
+ | 18 | | Beta | 1.4.0 released |
+ +------+-----------------+-----------------+------------------+
+
+Each stage can be defined as follows:
+
+ Development Beta Polish
+ Python Frozen: - slushy Y
+ Docstring Frozen: - slushy thicker slush
+ C code Frozen: - thicker slush thicker slush
+
+Terminology:
+
+ * slushy: you can change it if you beg the release team and it's really
+ important and you coordinate with docs/translations; no "big" changes.
+
+ * thicker slush: you can change it if it's an open bug marked
+ showstopper for the Polish release, you beg the release team, the
+ change is very very small yet very very important, and you feel
+ extremely guilty about your transgressions.
+
+The different frozen states are intended to be gradients. The exact meaning is
+decided by the release manager: he has the last word on what's go in, what
+doesn't.
+
+The proposed schedule means that there would be at most 4 months between
+putting code into the source code repository and being released.
+
+Release team
+------------
+
+For every release, there would be at least one release manager. We propose to
+rotate the release manager: rotation means it is not always the same person
+doing the dirty job, and it should also keep the release manager honest.
+
+References
+==========
+
+ * Proposed schedule for Gnome from Havoc Pennington (one of the core
+ GTK and Gnome manager):
+ http://mail.gnome.org/archives/gnome-hackers/2002-June/msg00041.html
+ The proposed schedule is heavily based on this email
+
+ * http://live.gnome.org/ReleasePlanning/Freezes
Deleted: trunk/doc/release/time_based_proposal.txt
===================================================================
--- trunk/doc/release/time_based_proposal.txt 2009-02-27 07:21:23 UTC (rev 6502)
+++ trunk/doc/release/time_based_proposal.txt 2009-02-27 07:23:01 UTC (rev 6503)
@@ -1,106 +0,0 @@
-.. vim:syntax=rst
-
-Introduction
-============
-
-This document proposes some enhancements for numpy and scipy releases.
-Successive numpy and scipy releases are too far appart from a time point of
-view - some people who are in the numpy release team feel that it cannot
-improve without a bit more formal release process. The main proposal is to
-follow a time-based release, with expected dates for code freeze, beta and rc.
-The goal is two folds: make release more predictible, and move the code forward.
-
-Rationale
-=========
-
-Right now, the release process of numpy is relatively organic. When some
-features are there, we may decide to make a new release. Because there is not
-fixed schedule, people don't really know when new features and bug fixes will
-go into a release. More significantly, having an expected release schedule
-helps to *coordinate* efforts: at the beginning of a cycle, everybody can jump
-in and put new code, even break things if needed. But after some point, only
-bug fixes are accepted: this makes beta and RC releases much easier; calming
-things down toward the release date helps focusing on bugs and regressions
-
-Proposal
-========
-
-Time schedule
--------------
-
-The proposed schedule is to release numpy every 3 months - the exact period can
-be tweaked if it ends up not working as expected. There will be several stages
-for the cycle:
-
- * Development: anything can happen (by anything, we mean as currently
- done). The focus is on new features, refactoring, etc...
- * Beta: no new features. No bug fixing which requires heavy changes.
- regression fixes which appear on supported platforms and were not
- caught earlier.
- * Polish/RC: only docstring changes and blocker regressions are allowed.
-
-The schedule would be as follows:
-
- +------+-----------------+-----------------+------------------+
- | Week | 1.3.0 | 1.4.0 | Release time |
- +======+=================+=================+==================+
- | 1 | Development | - | |
- | 2 | Development | - | |
- | 3 | Development | - | |
- | 4 | Development | - | |
- | 5 | Development | - | |
- | 6 | Development | - | |
- | 7 | Beta | - | |
- | 8 | Beta | - | |
- | 9 | Beta | - | 1.3.0 released |
- | 10 | Polish | Development | |
- | 11 | Polish | Development | |
- | 12 | Polish | Development | |
- | 13 | Polish | Development | |
- | 14 | | Development | |
- | 15 | | Development | |
- | 16 | | Beta | |
- | 17 | | Beta | |
- | 18 | | Beta | 1.4.0 released |
- +------+-----------------+-----------------+------------------+
-
-Each stage can be defined as follows:
-
- Development Beta Polish
- Python Frozen: - slushy Y
- Docstring Frozen: - slushy thicker slush
- C code Frozen: - thicker slush thicker slush
-
-Terminology:
-
- * slushy: you can change it if you beg the release team and it's really
- important and you coordinate with docs/translations; no "big" changes.
-
- * thicker slush: you can change it if it's an open bug marked
- showstopper for the Polish release, you beg the release team, the
- change is very very small yet very very important, and you feel
- extremely guilty about your transgressions.
-
-The different frozen states are intended to be gradients. The exact meaning is
-decided by the release manager: he has the last word on what's go in, what
-doesn't.
-
-The proposed schedule means that there would be at most 4 months between
-putting code into the source code repository and being released.
-
-Release team
-------------
-
-For every release, there would be at least one release manager. We propose to
-rotate the release manager: rotation means it is not always the same person
-doing the dirty job, and it should also keep the release manager honest.
-
-References
-==========
-
- * Proposed schedule for Gnome from Havoc Pennington (one of the core
- GTK and Gnome manager):
- http://mail.gnome.org/archives/gnome-hackers/2002-June/msg00041.html
- The proposed schedule is heavily based on this email
-
- * http://live.gnome.org/ReleasePlanning/Freezes
More information about the Numpy-svn
mailing list