For newer information, see automated release process in OpenCSW manual.

Background

As of January 2009, OpenCSW mirrors offer two releases: current and stable¹. The unstable release is a symlink to current. In the current release process, individual packages are submitted to the release manager, who updates current. The stable release is not getting any updates, even security updates. It's there only for the purpose of backward compatibility.

The main problem is that there are currently no processes that might potentially lead to a stable release. The current branch is never tested enough to qualify for a stable release. Unless the process is modified, there is no way a stable release can be ever made.

There is a branch called testing, which used mostly by maintainers; its purpose is to make newly built packages available for people to download and try out before they are submitted for release. As of January 2009, it contains a lot of packages and it's not suitable as a whole, even for testing purposes, mainly because it often contains broken or conflicting packages.

Overview

There is a number of constraints, for the modified process:

• No requirement for large amounts of developer / maintainer time
• The target state should be intuitive for people not well acquainted with OpenCSW
• The stable catalog must undergo integrated testing, meaning that the catalog has been tested as a whole

The modified process should not require much additional work; instead it should help the project separate the wheat from the chaff, so that stable releases can eventually become (more) regular occurrences.

Goals

• Creating a process capable of making a stable release
• Regular releases

Non-goals

• Fixing bugs in all the packages
  • There is no manpower to fix all the existing bugs. The goal is not to create a catalog where all the packages are high quality. Instead, the goal is to create a catalog in which the high quality criteria apply to a selected subset of packages.

Where do we want to be

The release branch naming and meaning will be modeled on Debian's: named releases, also labeled as unstable, testing and stable.

Releases

experimental

There's no experimental branch on the official mirror. There are per-project experimental branches available for maintainers to drop packages into.

• receives individual packages from maintainers
• might be subdivided into multiple catalogs, for purposes of individual maintainers, or projects (gnome update, perl 5.10.x update)
• no quality assurance
• quality level equivalent to the old testing/.

unstable

• receives individual packages from maintainers

testing

• updates flow into testing from unstable in an automatic and/or a manual way; if there are no new bugs filed against an updated package in unstable for 2 weeks, the updated package is automatically integrated into testing

stable

• created by promoting a testing branch when:
  • no bugs for tier 1 (core) packages are open in the testing release
  • the upgrade process from the previous stable has been tested and documented
• does not receive any individual packages unless an exception must be made
• can receive, as an exception, an individual package upgrade, but only if:
  • it's a security fix
  • it's a serious bug fix
  • it's not a version upgrade

The diagram

The testing process

Integrated testing

Integrated testing is the vital part of the new process. It means that the testing isn't concerned with individual packages, but the catalog as a whole. This would catch things such as shared library linking inconsistencies and conflicting package versions.

Individual package testing

On top of that, packages must be closely examined by people who understand the packages and can do meaningful checks.

Release upgrade testing

With well-defined sets of packages, e.g. a given stable and testing, the upgrade process can be tested. It involves creating a Solaris² installation with the older branch (stable) and performing Tier 1 (core) packages upgrade to testing. All the upgrade issues need to be either fixed (by pushing package fixes to testing) or documented, with instructions how to work around the problems.

Package tiering

See the package tiering page.

Named releases

When the unstable gets snapshotted, it's snapshotted to a directory tagged with year and a month, in the releases/ directory. testing and stable are symlinks to specific releases. An example layout:

opencsw
|-- compat
|   |-- dublin
|   |-- legacy
|   `-- paris
|-- dists
|   |-- dublin
|   |   |-- core
|   |   |-- main
|   |   `-- unsupported
|   |-- legacy
|   |   |-- core
|   |   |-- main
|   |   `-- unsupported
|   `-- unstable
|       |-- core
|       |-- main
|       `-- unsupported
|-- releases
|   `-- legacy -> ../dists/legacy
|-- stable -> releases/legacy
|-- testing -> dists/paris
`-- unstable -> dists/dublin

• Promoting testing to stable means only flipping a symlink
• Users, if they wish to, can subscribe to certain releases and do upgrades as they see fit, instead of us flipping the symlink. This would not be a recommended practice, but if a user believed it would help them, it would be possible.
• Older releases can stay around for a while, until we remove them. They can be used as a better version of oldpkgs, preserving an older version of stable.
• All releases would eventually become stable, so the list of past releases is the historic list of previous stable directories.

[dam: Implementation details: where should allpkgs/ go? Where would we put the catalog for the Sun-Replacement-Packages CSWsunwsendmail, …?]

How do we get there

Milestone 1: The target catalog layout

Person in charge of this milestone: Dagobert Michelsen.

1. Done (without redirection): Move http://mirror.opencsw.org/testing.html to http://mirror.opencsw.org/experimental.html and create a HTTP redirect so the old URL still works, update the page content so that the example commands point at the right URL
2. Done: Create the experimental/ catalog
3. Done: Move catalog content from testing/ to experimental/
4. Done: Create /home/experimental (to replace /home/testing)
5. Done: Move all packages from /home/testing to /home/experimental
6. Remove /home/testing
7. Done: Make sure that automatic package propagation from /home/experimental to http://mirror.opencsw.org/experimental.html works properly
8. Remove the unstable symlink (to current)
9. Create a new unstable catalog
10. Copy catalog content from current to unstable (note: new unstable has the same quality level as the old current)
11. Move current to testing
12. Make a symlink from current to testing (backward compatibility)
13. Create releases directory (dam: functionality similar to current testing/ as released packages get automatically removed)
14. Move stable to releases/2008.04 (the newest REV= in stable is April 2008)
15. Make a symlink from stable to releases/2008.04

The target layout:

.
|-- current -> unstable
|-- experimental
|-- releases
|   |-- 2008.04
|   `-- 2010.02
|-- stable -> releases/2008.04
|-- testing -> releases/2010.02
`-- unstable

At this point, there are no major changes for the users. The only change in the release process is that released packages go into unstable instead of current, but this change is not affecting users subscribed to current, because it's a symlink to unstable.

Milestone 2: The tools

In order to make the releases efficiently, we need specific tools. The most important part is bug accounting.

Here's the list of tasks:

• Done: a tool to generate catalogs out of nested directories (→ Dago)
• synchronize versions of all released packages to be visible in Mantis (→ Sebastian)
• bugs can be reported against specific package versions (→ Sebastian)
• it will be possible to make a list of all open bugs in a catalog like stable/ (→ Sebastian)
• implement tier (1/2/3) information storage in mantis (→Sebastian)
• assign tiers to packages (coordinated by Dago)

Milestone 3: The release cycle

• Done (Maciej): New individual packages get released into unstable/ using an automated tool.
  • Done (Ben): Packages uploaded to unstable/ are published in an atom feed, together with their checkpkg results
• Packages from unstable/ that have no bugs filed against them, are promoted to testing/
• One month before the stable release, a feature freeze occurs
  • Version upgrades of packages in core as discouraged until the release
  • Tier 1 (core) packages in testing/ get tested by respective maintainers: does the configuration migration go OK? Does the application actually work after the upgrade?
• When the upgrade procedure is tested, and the right time comes, a stable release occurs:
  • Named release, e.g. dublin, is marked as stable
  • Next named release, e.g. kiel, is created and marked as testing
• GOTO 10

Caveats

Package tiering

Introducing package tiering might be quite time-costly by itself. It's hard to estimate how much work it will take; if it's too much work, the Tier 1 (core) set of packages should be kept to minimum and expanded if both necessary and possible.

(the idea has been abandoned)

Release schedule

Ideally, the releases would occur in regular time intervals. The time at which a snapshot of the unstable branch is taken might be important. Sometimes, it's not a good idea to take a snapshot of a catalog which has serious problems. If a fix is underway, the release can be deferred by some amount of time (a couple of days or a week). However, it shouldn't be deferred too much, because this might allow new problems to crop out. It's better to make a snapshot of a broken unstable and work on fixing it.

The other problem with creating releases is that it might happen that when the release season comes, the last snapshot might be not yet ready for promotion to stable. In such case, the new snapshot would be not made, and the work on the testing release would continue until it's promoted to stable. Only then the new snapshot would be made.

Orphaned low-quality packages

There might be occurrences of packages which don't qualify for stable, and don't have anybody willing to work on them. In such case, these packages might be moved to the unstable catalog, or removed entirely. If a package is considered important, the community needs to discuss

Links

See also

• Release process
• Package tiering
• Automated release process
• Wintercamp 2009 minutes (the text file linked from the bottom of the minutes page)