proposed 2.2 release schedule

[Luis Villa <louie ximian com>]

So... we're very nearly at the 2.0.1 release, and a lot of people are
itching to start on 2.2. Which maybe means we need a schedule. Here's
the current thinking of the release team. We'd like to finalize this RSN
so please send your thoughts and feedback and flames and such ASAP. :)
It's important all the way through, so please read all of it :) 'Other
notes' in particular deserve thought. 

Most Important Dates: 
[followed by things which start on that date] 
        * after 2.0.2[0]: Begin work on 2.1.x.
            * hackers focus on: cool stuff :), listing that cool stuff
              so that everyone else knows what is going on
            * UI/a11y focus on: finishing documentation for all hackers
              to use[1]
        * Oct. 31st: feature freeze, UI chill[2], completion of UI/a11y
          docs
            * hackers focus: feature completion, bug fixing
            * UI/a11y teams: identify bugs in UI- all UI changes should
              be approved by UI/a11y teams after 'chill' starts
            * marketing and QA: get a hard feature list, inc. new
              modules[3]
        * Nov. 30th: UI freeze except for fixing of bugs filed by
          UI/a11y teams
            * hackers focus: fix bugs
            * QA: identify features that are incomplete and must wait
              for 2.4, and notify marketing of the things that are
              getting dropped
            * UI/a11y: assist hackers in fixing bugs identified before
              freeze[4]
        * Four weeks before RC [12/28]: hard i18n string freeze
            * after this point, fixes (_including_ UI/a11y) go in only
              if they have no string impact and low stability risk.
            * Note that this is specified as 'four weeks before RC' on
              the supposition that if the RC is moved for quality
              reasons string freeze should also be moved.
        * Jan. 31st: 2.2.0 release
            * hackers, release team, others: drink heavily
            * QA team: read bugs, drink more heavily
            * rinse, repeat for 2.4

RELEASES (very tentative, based roughly on the current three-week
cycle):
        * 2.0.2: Week ending Sept. 6th
        * 2.1.0: " Sept. 27th
        * 2.1.1: " Oct. 18th: 'October GNOME, take two'
        * 2.1.2: " Nov. 1st: the 'UI and a11y teams, do your worst'
          release [Note only a two week cycle here]
        * 2.1.3: " Nov. 22nd: the 'last chance to report UI/a11y bugs'
          release
        * 2.1.4: " Dec. 13th: the 'last chance to report string bugs'
          release
        * 2.1.5: " Jan. 3rd: the 'release that will never happen because
          no one will want to roll tarballs this close to new years'
          release[5]
        * 2.1.90 (RC1): " Jan. 24th: the 'these tarballs should be
          final' release[6]
        * 2.2.0: Jan. 31st: the 'release' release

FOOTNOTES:

[0]Or after 2.0.1 for apps that feel they are Ready. Ready is a
judgement call, of course... certainly the more bugfixing between 2.0.1
and 2.0.2 the better off we'll be when we start 2.1, so we strongly
encourage most modules to wait until after 2.0.2 :)

[1]It is my firm belief that if there are no complete HIG/a11y docs,
we're never going to have decent compliance with either of these, and so
those teams would have three months from today to complete those docs so
that hackers can use them. Bugs not covered by those documents will not
be considered high priority for the 2.2 release. The teams would still
have three months after document completion to ID bugs and fix them
before 2.2.0. 

[2] Past this point, UI is in the hands of the usability and a11y teams;
hackers should have done from a UI perspective everything they want to
do at this point. If hackers want to add more UI at this point, it has
to go by the UI and a11y teams.

[3] Anything on this list not of sufficient quality by Nov. 31st will be
dropped at that time.

[4] If the UI and a11y teams have not identified a problem by the
31st, unless it is of the utmost severity, it's a 2.4 thing. Bugs
they've identified by this point are still fixable in the 2.4 time frame
and can become release blockers. [a11y bugs that don't impact
UI/doc/string freeze can be identified/fixed after this date, of
course.]

[5] Eck. Totally hadn't considered the need for RCs when thinking about
January 31st as a release date. Any thoughts on that?

[6] effectively this gives (with tarballs for a rc theoretically final)
only three weeks for i18n. This is probably too short.
Suggestions/comments, Kjartan, Menthos, rest of i18n team?

Other notes:
*this is a schedule centered around 30/31 day cycles, not 3 week cycles
as per our last one. This introduces some issues- like a release on
January 3rd. :/

*The marketing team feels strongly that we should aim for mid-January so
that we can announce at LinuxWorld New York, which would be pretty cool.
Much of the rest of release team is worried about hackers and their
availability and willingness to hack during January. It's a noble goal-
if we believe we can hit it. Thoughts/comments?

*This doesn't touch the issue of API freezes for core libraries; /if/ we
think this is going to actually be an issue then we really need to
address it. 

*Release numbering- what do maintainers think about numbering their
releases based on the gnome release? i.e., 2.1.1.0 for the release that
goes out with GNOME 2.1.1, 2.1.1.1 for the first snap release after
2.1.1, etc.? This is really sort of micro-managerial so we're reluctant
to ask this, but it would help packagers and general organization. 

*We need to think about criteria for the 2.0.x series and its releases
in a separate discussion, IMHO, but it definitely needs to be talked
about- who is going to do it, when it will be done, how we decide when
it will be done, etc.

Tiredly and on behalf of the release team-
Luis