LandscapeUpdates
|
Size: 2265
Comment:
|
Size: 3394
Comment: draft approved by TB
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| '''DRAFT, DO NOT COMMENT ABOUT THIS YET - Andreas - Jan/2008''' | This document describes the policy for updating Landscape client packages in a stable supported distro, including LTS. It is also the aim of this document to provide an example for any upstream project that wants to push updates to an Ubuntu stable release. |
| Line 3: | Line 3: |
| This document describes the policy for updating Landscape client packages in a stable supported distro, be it LTS or not. Landscape is a commercial service from Canonical which periodically offers new features to its customers. Being a client-server product, the client part needs to be periodically updated in order to take advantage of the new features. Therefore, new features are allowed in an update '''as long as the conditions outlined below are met'''. |
Landscape is a commercial service from Canonical which periodically offers new features to its customers. Being a client-server product, the client part needs to be periodically updated in order to take advantage of the new features. Therefore, in addition to bug fixes, new features are allowed in an update '''as long as the conditions outlined below are met'''. |
| Line 9: | Line 7: |
| * each change must have a Launchpad ticket filed under the landscape-client project | * each change must have a Launchpad ticket filed under the landscape-client project (https://bugs.launchpad.net/landscape-client/+filebug). Packaging bugs should be filed against the landscape-client ubuntu package (https://bugs.launchpad.net/ubuntu/+source/landscape-client/+filebug) |
| Line 11: | Line 9: |
| * two developer reviews approving the change (already a standard Landscape coding practice) * a specific QA review * all self tests must pass (already a standard Landscape coding practice) * after the upgrade, the client must still be able to talk to the Landscape server The above tests exercise the code changes. The packaging changes need an extra QA procedure outlined below. |
* a bzr branch attached with the fix + tests * two Landscape developer reviews approving the change (already a standard Landscape coding practice) * a specific QA review. The QA engineer must at least do a before and after kind of test, corroborating the fix. * a "Committed" status, meaning the change is already in the code base * all the code changes must be covered by tests * all self tests must pass. Being a project that follows the TDD model (Test Driven Development, see http://en.wikipedia.org/wiki/Test_driven_development for details), any code change in Landscape (client or server) is covered by a test. The client part has, as of version 1.0.23, 1469 individual test cases that cover the entire code base. The above tests exercise the code changes and must be performed by a member of the Landscape team. The packaging changes need an extra QA procedure outlined below. |
| Line 23: | Line 23: |
| * upgrade test from previous distribution to the current one. If the current distribution is an LTS one, the upgrade path from the previous LTS distro must also be exercised. This upgrade test must be performed using do-release-upgrade | * upgrade test from previous distribution to the current one. If the current distribution is an LTS one, the upgrade path from the previous LTS distro must also be exercised. |
| Line 25: | Line 25: |
| * dpkg | |
| Line 27: | Line 26: |
| * smart install/upgrade | |
| Line 30: | Line 28: |
| * using dpkg | |
| Line 32: | Line 29: |
| * using smart * optionally, because of the added complexity and because the author of this document is not yet sure how to do it, the installer of the current distribution should also be tested using the new package to make sure it works in the installer environment |
* test interaction with update-motd to make sure the motd doesn't get trashed or otherwise impaired by landscape-common: * reboot and make sure motd is displayed correctly and not trashed * when update-motd is used by landscape-sysinfo (it's the default), make sure its call to landscape-sysinfo works and the output is included in the motd * provoke an error (backtrace) in landscape-sysinfo plugin by running `sudo chmod 0 /proc`: the backtrace must not be included in the motd The above tests can be performed by any QA engineer. == Requesting the SRU == The SRU should be requested as usual ([[StableReleaseUpdates]]) with the additional note about having the above steps being completed. |
This document describes the policy for updating Landscape client packages in a stable supported distro, including LTS. It is also the aim of this document to provide an example for any upstream project that wants to push updates to an Ubuntu stable release.
Landscape is a commercial service from Canonical which periodically offers new features to its customers. Being a client-server product, the client part needs to be periodically updated in order to take advantage of the new features. Therefore, in addition to bug fixes, new features are allowed in an update as long as the conditions outlined below are met.
QA Process
This is the mandatory QA process that the proposed packages have to pass. The following requirements must be met:
each change must have a Launchpad ticket filed under the landscape-client project (https://bugs.launchpad.net/landscape-client/+filebug). Packaging bugs should be filed against the landscape-client ubuntu package (https://bugs.launchpad.net/ubuntu/+source/landscape-client/+filebug)
- each one of those tickets must have:
- a bzr branch attached with the fix + tests
- two Landscape developer reviews approving the change (already a standard Landscape coding practice)
- a specific QA review. The QA engineer must at least do a before and after kind of test, corroborating the fix.
- a "Committed" status, meaning the change is already in the code base
- all the code changes must be covered by tests
all self tests must pass. Being a project that follows the TDD model (Test Driven Development, see http://en.wikipedia.org/wiki/Test_driven_development for details), any code change in Landscape (client or server) is covered by a test. The client part has, as of version 1.0.23, 1469 individual test cases that cover the entire code base.
The above tests exercise the code changes and must be performed by a member of the Landscape team. The packaging changes need an extra QA procedure outlined below.
Packaging QA
The objective of the separate packaging QA is to test:
- package upgrades
- package installation from scratch
- distribution upgrade
The resulting package, with all the changes in place, must undergo and pass the following additional QA procedures:
- upgrade test from previous distribution to the current one. If the current distribution is an LTS one, the upgrade path from the previous LTS distro must also be exercised.
- upgrade test from previous version of the package. This test must be performed with:
- apt-get install/upgrade
- using the Landscape service itself
- installation from scratch in the current distribution:
- using apt-get
- test interaction with update-motd to make sure the motd doesn't get trashed or otherwise impaired by landscape-common:
- reboot and make sure motd is displayed correctly and not trashed
- when update-motd is used by landscape-sysinfo (it's the default), make sure its call to landscape-sysinfo works and the output is included in the motd
provoke an error (backtrace) in landscape-sysinfo plugin by running sudo chmod 0 /proc: the backtrace must not be included in the motd
The above tests can be performed by any QA engineer.
Requesting the SRU
The SRU should be requested as usual (StableReleaseUpdates) with the additional note about having the above steps being completed.
LandscapeUpdates (last edited 2025-06-25 18:55:27 by ahasenack)