Page History

...

The Athena 10 project will be a collaboration with the Debathena developers from SIPB and will also act as a follow-on to the current Debathena release. From IS&T, the primary developers will be Greg
Hudson (the release engineer and lead developer), Robert Basch, and Andrew Boardman, with Alex Prengel taking on the role of ensuring compatibility with third-party software lockers. From the SIPB, the contributors will be Tim Abbott and Anders Kaseorg.

Goals

• The supported base operating system will be Ubuntu 8.04 (Hardy Heron), which is due out in April 2008 and is tagged by Canonical as a long-term support release. Development will mostly take place on Ubuntu 7.10 (Gutsy Gibbon).

• The build infrastructure and package repository will also support versions of Debian and other versions of Ubuntu. These operating system versions will be supported by SIPB rather than IS&T.

• When a software package exists in the Ubuntu package archive, we will not build it ourselves from the upstream source. In cases where a change is necessary, we will use a script to rebuild the relevant Ubuntu and Debian source packages with a patch applied.

• We will plug into system features such as PAM and NSS to avoid having to replace core parts of the base platform.

• We will use autofs on /mit to remove the need for users to manually attach lockers (though the attach command will remain for compatibility and system notifications).

• We will make our configuration packages as modular as possible, rather than bundling them all up into an athena-ws package.

• We will use the standard /usr path prefix for Athena software rather than using a separate tree in /usr/athena. There will be a big package of compatibility symlinks to ensure that most old path references keep working.

• The update system will no longer be organized around specific patch releases. This change will allow us to better leverage the native update system and will also enable machines to take native package updates as soon as they become available, which will improve security.

...

• Continue to support the familiar user interface.
• Continue to support "Public Cluster" systems that clean themselves up after each user logs out.
• Continue to support the existing "Quickstation" systems tailored for shorter duration sessions.
• Allow installation of Athena on an already-installed Linux system without an Operating System re-install.
• Un-bundle the components to allow customers the option to pick and choose which pieces of Athena they want.
• Retire functionality that is no longer used, or is no longer of sufficient benefit to warrant the ongoing maintenance cost.
• Replace more of MIT invented or maintained components with upstream open source components, where necessary migrating to community standard practices rather than Athena-unique practices.

Release Deliverables

The deliverables for the Athena 10 release are:

• A set of packages containing Athena original software (e.g. Larvnet, attach, etc.) with names like debathena-discuss.

• A set of packages controlling configuration of other packages (e.g. sshd) with names like debathena-hesiod-config.

• A set of packages to perform self-maintenance (e.g. to clean up temporary directories).

• Source repositories for software which has Ubuntu packages, but for which we are the upstream maintainer (e.g. Zephyr).

• An-automated-update-from-Athena-9.4. Eliminated from scope c. July 2008.

• A script to install Athena 10 on a pre-installed Ubuntu syatem.

• A comprehensive Cluster Installer to install Ubuntu and Athena 10 on bare metal.

• Release notes and documentation, particularly for aspects of Athena 9.4 which become desupported or supported in different ways.

Design Decisions

• The supported base operating system will be Ubuntu 8.04 (Hardy Heron), which is due out in April 2008 and is tagged by Canonical as a long-term support release. Development will mostly take place on Ubuntu 7.10 (Gutsy Gibbon).

• Subsequent Athena OS updates will be taken from the Ubuntu 6-month release cycle. Although this will be more work because of greater frequency, the 6-month release offers the most useful versions of applications and drivers. The plan is to deploy the x.10 release in January and the x.04 release over the summer.

• The build infrastructure and package repository will also support versions of Debian and other versions of Ubuntu. These operating system versions will be supported by SIPB rather than IS&T.

• When a software package exists in the Ubuntu package archive, we will not build it ourselves from the upstream source. In cases where a change is necessary, we will use a script to rebuild the relevant Ubuntu and Debian source packages with a patch applied.

• We will plug into system features such as PAM and NSS to avoid having to replace core parts of the base platform.

• We will use FUSE on /mit to remove the need for users to manually attach lockers (though the attach command will remain for compatibility and system notifications).

• We will make our configuration packages as modular as possible, rather than bundling them all up into an athena-ws package.

• We will use the standard /usr path prefix for Athena software rather than using a separate tree in /usr/athena. There will be a big package of compatibility symlinks to ensure that most old path references keep working.

• The update system will no longer be organized around specific patch releases. This change will allow us to better leverage the native update system and will also enable machines to take native package updates as soon as they become available, which will improve security

...

Release Deliverables

The deliverables for the Athena 10 release are:

• A set of packages containing Athena original software (e.g. Larvnet, attach, etc.) with names like debathena-discuss.

• A set of packages controlling configuration of other packages (e.g. sshd) with names like debathena-hesiod-config.

• A set of packages to perform self-maintenance (e.g. to clean up temporary directories).

• Source repositories for software which has Ubuntu packages, but for which we are the upstream maintainer (e.g. Zephyr).

• An automated update from Athena 9.4.

• An installation system.

• Release notes and documentation, particularly for aspects of Athena 9.4 which become desupported or supported in different ways.

...

1. DONE 3/18/08 Infrastructure - Development infrastructure in place including source tree and build scripts. Ubuntu machines in the hands of Andrew and Bob so that they may begin work.
2. DONE 6/30/08 Core - The fundamental building blocks of the Athena environment are in place (AFS, login, incremental updates, etc). Due date: April 30.
3. DONE 7/25/08 Basic - The high-profile Athena applications are in place (Firefox, email, etc.). Due date: June 30. Bigest scheduling issue: email clients.
4. DONE 8/15/08 Preview - Enough features are in place for release to private machines on an opt-in basis. Backward compatibility features are not a big concern for this milestone if they are not expected to receive heavy use. Biggest scheduling issue: printing. Due date: August 15.
5. Cluster - Self-maintenance features and GNOME modifications necessary for cluster machine deployments are in place. Alpha testing can begin once this milestone is complete. The-updater-is-complete. (Updater eliminated from scope c. July 2008). Due date: October 1. Biggest scheduling isue: The-updater The comprehensive installer.
6. DONE 12/12/08 Feature Complete - Remaining release features are completed. The-installer-is-complete. (Installer moved to Cluster milestone.) System release notes are complete. Backward compatibility issues are
   substantially resolved. Due date: November 1. Biggest scheduling issue: The-installer.
7. Beta Testing Complete - Acceptance testing is complete and Athena 10 is ready for "early release" deployment. User release notes are complete. Due date: November 1.
8. Full Deployment Readiness - Early release is complete and Athena 10 is ready to be released to all cluster machines. Due date: December 1

...

Design Plans For Release Features

...

In total, these design plans account for about 24 weeks of work, or about two months per developer. Additional work will be required for the installer, the updater, integration testing, and documentation.

...