The Athena Release

Introduction

The Athena Release integrates MIT-invented services, as well as third party software and services into standard Solaris and Red Hat Enterprise Linux operating systems.

Life Cycle

The life-cycle of the Athena Release is built around the school year. The beginning of a new term is the time to introduce user-visible changes. During the term it's important to keep things as stable as possible. What engineers might classify as bug fixes, customers might perceive as disruptive breakage. For example, class notes explaining how to use software might require an update. Therefore testing and roll-out of large scope, user-visible changes happens over the summer. Smaller scope changes are tested and rolled-out over IAP.

The testing cycle for the annual major release and patch releases is detailed in the document Athena Release Testing Cycle. The document also names the dates when new hardware protypes and production rollouts are best met.

Change Management

Change management follows the following principles in order of decreasing priority:

1. Minimize disruption to the customers.
2. Keep systems secure.
3. Keep in sync with supported versions of vendor-supplied hardware and operating systems.
4. Minimize overall cost to MIT.
5. Provide bug fixes to existing services.
6. Provide enhancements or new functionality.

Considerable thought goes into minimizing disruption. Security fixes sometimes go out immediately to stop likely or active disruptions. Most times they go out during a regular patch test and release cycle each month.

During the term, from Drop Date to the end of exams, we prefer to make no changes whatsoever. During that time we would consider introducing a change only in cases of a severe bug affecting many users, or an actively exploited security vulnerability.

[Back to top]

The Athena Source Tree

The following documents detail the organization of and policies governing the Athena source tree:

• organization -- describes how the Athena source tree is organized.
• procedures -- describes the process developers should go through to get changes into the source tree.
• build-system -- explains how to build packages from the Athena source tree, and then describes guidelines for designing the build system for code we maintain in the Athena source tree.
• third-party -- names the third-party software we build locally and describes how we build it.
• standards -- describes guidelines for code which is to be incorporated into the Athena source tree.

[Back to top]

Useful Email Lists

Post to:

• software-suggestions@mit.edu to suggest what should be in the next release, or what should change.
• bugs@mit.edu to report bugs in the Athena Release.

Subscribe to:

• release-announce to receive announcements about new releases whether they be major or minor.

Read Archives of:

• release-team team discussion list.

[Back to top]