[openi18n-im:01177] [Proposal] IIIMF project schedule

Hello,

To improve the project, I would like to start a discussion on varies
points on schedule and release engineering by suggesting an improvement
proposal.

Please tell us if you have any concerns on this model, or any
questions / improvements on this.

We will need couple of roles:
- feature/schedule tracker
- release engineers
- QA

It would be great if there are any volunteers. If not I would like to
propose myself for this year to look across feature/schedule tracking,
Jens Petersen and I be the release engineers, and Lawrence Lim be the QA
organizer.


Background
----------
Since last year the im-sdk project has been more organized on committing
features and releasing new versions. However there are still clear
development cycle from the point of views of community contributors, so
there is not clear guidance about when is the right time to contribute
new work into trunk, or when there is feature freeze and contributors
need to stop adding new code into trunk to allow for stabilization.

Rationale
---------
There are several goals of maintaining a project:
1. To fulfill new features for users - increase their experiences on the
software/technology
2. To ensure releases are stable
3. To create a good development process for contributors and testers
4. To advance the technology through cycles

Current method of release engineering in im-sdk project:
--------------------------------------------------------
- Features are declared with approximation of delivery
- All feature contributions are allowed into trunk
- There is a (feature-based) version cut off date
- On the version cut off date, all of the code in trunk is tagged as the
version
- We also introduced two basket system - trunk for committing new
features, and trunk and a branch for throwing in fixes.

** Advantages
- Simple
- Easy to manage

** Disadvantages
- No clear known release date and roadmap
- There is no time for testers to QA the state before it gets released
- No clear date on when to release a minor version to fix the current
version's issues
- Vendors/Distros has a hard time deciding what bits to ship and
maintaining it

Proposed implementation
-----------------------
** Release Cycles:
"Release early and often" works well in most OSS projects.  It has a
number of advantages:
1. Attracts more users: many users are afraid to use trunk because it is
not guaranteed to work.
2. It gets more testing and hence more bug reports/improvement
suggestions.
3. While it is hard to suit all distributions' and other projects'
schedules, having shorter development cycles and time between releases
means they can choose which one to include without too much trade-off in
the latest features.

** Example Schedule:
          :        |
Jan       :      trunk
          :        |
Feb    12.1.2      |
                   |
Mar                |
                   |
Apr              12.2 ----- trunk
                   :          |
May                :          |
                   :          |
Jun              12.2.1       |
                              |
Jul                           |
                              |
Aug                         12.4 ---- trunk
                              :         |
Sep                           :         |
                              :         |
Oct                         12.4.1      |
                                        |
Nov                                     |
                                        |
Dec                                   12.6 ----- trunk
                                        :          |

Most development and maintenance takes place in either trunk or a svn
branch at any one time.  Trunk contains the latest and greatest and is
where new features are added.  The branch is based on the last major
release and is largely maintenance only for resolving bugs and issues
with the last release.

Now users/vendors/distros can choose if:
- they want the latest and greatest at the expense of less testing and
stability, or
- they want to have the more stable version sacrificing some new
features


** Components of a major release:
  Feature Freeze - No new features will be accepted after this milestone
  API/ABI Freeze - No API/ABI changes should be made in the platform so
that there is a stable API for the rest of the schedule.
  Code Freeze - No further code changes can be made
  QA Period - A period for testers to have frozen code to test on
  Release - Branch cut and final tarballs released

For example for 12.2 say:
  Feature Freeze - Feb 12
  API/ABI Freeze - Feb 28
  Code Freeze - Apr 22
  QA Period - Apr 25-27
  Release - Apr 29

** Components of a minor release:
  Code Freeze - No further code changes can be made
  QA Period - A period for tests to have a frozen code to test on
  Release - A period for engineers to release tar balls for the lib/app

For example for 12.2.1:
  Code Freeze - Jun 21
  QA Period - Jun 22-24
  Release - Jun 28


Regards,
Leon