Proposed release process/plans

[Havoc Pennington <hp redhat com>]

Hi,

Some people from the board and release team sat down to come up with a
proposal for what branches we will have after 2.0 is out, and what the
goals of those branches will be. This turned out to involve thinking
through the big picture of GNOME development for the next 18 months or
so.

Appended is the current proposal, pretty boring stuff but important
for everyone to be on the same page about. Nat has a more fun writeup
of it (involving DHTML!) that needs resyncing with the current
proposal, then it will probably hit dotplan.

Summary of the short-term plan: bugfix/polish 2.0 for 6-8 weeks after
release, allowing _small_ string/UI changes; but then after the 6-8
weeks we lock down 2.0 big time, with no more string/UI changes
_ever_, until 2.2.

Also part of the short-term plan is that we cut a 2-0 branch when
2.0.0 goes out, and all future 2.0.x releases are rolled from that
branch; HEAD becomes the pre-2.2 branch.

The key elements of the long-term plan: a stable branch that is
extremely locked-down, an unstable branch that is always compilable
and dogfood-quality, and time-based releases at 6 month intervals.

Full description of the proposal and rationale appended.

Havoc


The Rationale and Goals
====================================================================

There are two goals of a release strategy: to create stable releases,
and to generate a lot of excitement and productive work that moves the
software forward.

We have two branches for that reason, stable and unstable. They
correspond to these goals.

The goal of the stable branch is to become entirely locked-down:
strings, features, every last pixel; and to get rid of as many bugs as
we can within the confines of the existing UI and code architecture.

The goal of the unstable branch is to be an exciting and
forward-moving but USABLE BY TESTERS piece of software. This is just
the "release early, release often" principle.

The trick is to toggle the focus of the community of developers and
testers between these branches at the right times. At any given time,
"most people" will be compiling, using, testing the same branch.

If we get "stuck" on the stable branch and don't make the jump to
unstable, then pressure builds to add features to stable, stable
destabilizes, unstable stagnates and stops being usable because only a
few people are using it, and it's all downhill from there. If we get
stuck on the unstable branch, then we never provide anything to the
majority of end users - we become useful to hackers/testers only.

In practice, to avoid getting stuck we need to create the
circumstances to make the jump to unstable reliably:

   The unstable branch must always be dogfood-quality. 
   If testers can't test it by using it daily, they can't 
   make the jump. If the unstable branch becomes too unstable, 
   we can't release it on a reliable schedule, so we have
   to start breaking the stable branch as a stopgap.

If we keep things dogfood-quality at all times, then we should be able
to move to time-based rather than feature-based releases, because the
unstable version should always be usable for testers. If it's usable
for testers we should be able to reliably freeze for a couple months
and release something of high quality. So we release on a fixed
schedule, rather than when a fixed set of features are complete.

The proposed schedule is every six months; because that keeps even our
non-tester end users closely synced with what we're actually working
on, which means they always have the best stuff, and bug reports
remain relevant.

The Implementation Details
====================================================================

GNOME has multiple development streams. These are named 2.0, 2.2, 2.4,
and so on. There is always an "active stream." The active stream:

 - is what the release team worries about 
 - what the weekly snapshots are built for
 - what we want people to test
 - the one developers should be dogfooding
 - the one the bug triage team will worry about
 - etc.

Each development stream has four possible states: Development, Beta,
Polish, and Locked. The Beta and Polish states are divided by a
release, such as 2.0.0 or 2.2.0.

Here is a sample roadmap (this is not an actual timeline suggestion,
ignore the details of the dates).  Asterisk (*) means the stream is
the active stream.

 Month      2.0           2.2          2.4
 =====      ===           ===          ===
   1       Development     -            - 
   2       Development     -            - 
   3       Development*    -            - 
   4       Development*    -            -
   5       Beta*           -            -
   6       Beta*           -            -           2.0.0 released
   7       Polish*       Development    -
   8       Polish*       Development    -
   9       Locked        Development*   -
  10       Locked        Development*   -
  11       Locked        Beta*          - 
  12       Locked        Beta*          -           2.2.0 released
   1       Locked        Polish*      Development
   2       Locked        Polish*      Development
   3       Locked        Locked       Development*
   4       Locked        Locked       Development*
   5       Locked        Locked       Beta*       
   6       Locked        Locked       Beta*         2.4.0 released
   7       Locked        Locked       Polish*
   8       Locked        Locked       Polish*

                   Development     Beta     Polish       Locked
Dogfoodable:           Y            Y         Y            Y
Feature Frozen:        -           slushy     Y            Y
UI Frozen:             -           slushy   thicker slush  Y
String Frozen:         -           slushy   thicker slush  Y

API/ABI breakage:      -            -         -            -
API/ABI removal:       -            -         -            -
API/ABI additions:     Y            -         -            -

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, you coordinate with docs/translations,
                 the change is very very small yet very very
                 important, and you feel extremely guilty about your
                 transgressions.

 dogfoodable = it compiles and is mostly usable for daily work out of
               CVS. if the build breaks or basic functionality breaks, 
               the offending patch may be removed by the release team 
               or build sherriff.

 feature frozen = no new menu items, no new buttons. no avoidable
                  "bugfixes" that involve large code rewrites, 
                  no optimizations that involve large-scale 
                  restructuring.

 UI frozen = no pixels may be changed. no changes to icons, themes, 
             padding, etc.

 string frozen = no internationalized text may be changed.

The UI/string/feature freezes are intended to be a gradual gradient
instead of sharp lines, gradient is defined by the release team.

Any change which does not fit into the requirements for Development,
Beta, Polish, or Locked, must occur in a branch created ad-hoc for the
module undergoing the change. This includes ALL changes which are not
dogfoodable. People must be able to run and test the active stream at
all times.

State transitions are time-based, not feature-based. If a feature
isn't ready for the release of a stream, it should be postponed to the
next stream. You have to get all new features in during the
Development state, in dogfoodable form; this ensures that it will be
possible to get the feature debugged during the Beta state.

Dates for state transitions are flexible. If the release team feels
that 2 months of Beta or Polish is too much for a given release, it
can leave more time for Development.

CVS Branches:

 Month      2.0           2.2          2.4
 =====      ===           ===          ===
   1       HEAD            -            - 
   2       HEAD            -            - 
   3       HEAD*           -            - 
   4       HEAD*           -            -
   5       HEAD*           -            -
   6       HEAD*           -            -           2.0.0 released
   7       2-0 *         HEAD           -
   8       2-0 *         HEAD           -
   9       2-0           HEAD*          -
  10       2-0           HEAD*          -
  11       2-0           HEAD*          - 
  12       2-0           HEAD*          -           2.2.0 released
   1       2-0           2-2*         HEAD
   2       2-0           2-2*         HEAD
   3       2-0           2-2          HEAD*
   4       2-0           2-2          HEAD*
   5       2-0           2-2          HEAD*       
   6       2-0           2-2          HEAD*         2.4.0 released
   7       2-0           2-2          2-4*
   8       2-0           2-2          2-4*

The above branches are the only ones that remain alive for any length
of time. Temporary branches may be created ad-hoc to address freezes,
not-dogfoodable development, or whatever. Branches should be off the
long-term branch that they will land on. For example, a branch to
prepare the 2.0.1 release would have the 2-0 branch as its trunk and
be merged back to 2-0 eventually. Tags for 2.0.x tarballs would be on
the 2-0 branch.

Implementation note: the branch isn't actually called "2-0", the
precise branch name is "gnome-2-0", "gnome-2-2", etc. for modules that
use GNOME-wide branch names, and may be different for some modules.

Release team:

In the past we've had a release team for each release or each branch.
The proposal going forward is to have a single release team that
focuses on the active stream, and flames people who mess up any Locked
streams. Of course the team members can change over time, to keep 
current members from burning out. Also, the single release team may
choose to delegate subteams or individuals to handle specific branches
or tasks.

Application to 2.0.0
====================================================================

There are two options for how the Polish phase works post-2.0.0
release:

  - 2.0.1 in one month, 2.0.2 in two months, then enter Locked
  - 2.0.1 in 1.5 months (6 weeks), then enter Locked

Rough Outline of 2.2.0
====================================================================

In the proposed framework, release feature lists are predictions, not
goals. That is, the goal is to release 6 months after 2.0.0. The
feature list is a guess at what will be ready.

Realistically, features that will be ready to freeze in 4 months are
features that are either very small or already in roughly working
form. Here are some predictions:

 - GTK 2.2
 - multihead support in some core components e.g. the panel
 - Metacity if we decide to adopt it
 - VTE if we decide to adopt it
 - a prototype of a new file selector in libegg, used by
   some core apps
 - Nautilus/panel/control-center incremental enhancements
 - media framework and media player
 - application launch feedback
 - new apps that have been ported in the meantime, perhaps 
   GNOME Office.

All of these things are already being actively developed. Large
features that aren't in progress most likely won't make 2.2. But of
course they could - it's just a matter of whether they are
dogfood-quality within 4 months.

The schedule for the next 6 months could be something along these lines:

  July: 2.0.1
  August: 2.0.2
  September: 2.1.0
  October:   2.1.1 (alpha)
  November:  2.1.2 (beta)
  Late November: 2.1.3 (release candidate)
  Mid-December: another release candidate or the release
  Mid-January: the release if not done before holidays

This is something the release team will decide, though, within the
overall guidelines presented in this document.