The following is an approved resolution of the Ubuntu Technical Board. = Landscape stable update policy; criteria for other similar updates =
== Introduction ==
Canonical's Landscape team approached Ubuntu some time ago requesting an
update of the Landscape client packages in Ubuntu. The mechanics of this
were discussed extensively with the team responsible for approving
stable release updates, and the Ubuntu Technical Board was asked to
approve the policy. [1]
Landscape is a commercial service from Canonical for systems management.
There is a central server which communicates with a group of clients.
Each client is a system being managed using Landscape. For example, an
administrator might instruct Landscape to arrange for the same package
to be installed on all machines on their network, or to start the same
service on a defined group of machines.
As might be expected from this kind of design, there is a defined
protocol between the client and the server. While it is not absolutely
necessary for them to be kept in step, many features of newer servers
will be unavailable with older clients. Since client systems are
assigned to groups and expected to be manageable in parallel, it causes
significant user confusion when some of those client systems are
incapable of acting on certain administrative requests which other
clients will execute correctly.
At present, users of the Landscape service are typically instructed to
use a PPA [2] to work around this. However, since the `landscape-client`
package is part of Ubuntu, the Landscape team, and indeed many Ubuntu
developers, would prefer if it were actually useful to Landscape users.
== Rationale ==
Since the `landscape-common` package, which is built from the
`landscape-client` source package, is installed by default (and
`landscape-client` itself has been installed by default in the past),
special care is needed to ensure that extensive updates to it do not
cause a problem either for users of the Landscape service or for
ordinary users of Ubuntu. `landscape-common` provides system information
in the message of the day (MOTD) even for people who have not signed up
to the Landscape service.
Members of the ubuntu-sru team have been discussing the quality
assurance issues related to this kind of update with the Landscape team
for some months. The proposed policy [1] includes an unusually strict QA
process as a result of these discussions. Tests are required for all
changes, each change must be signed off by two Landscape developers and
have a specific QA review, and a variety of fresh install and upgrade
combinations must be explicitly tested, including specific tests for the
MOTD handling provided by default. The Landscape and ubuntu-sru teams
have agreed that this process is an acceptable amount of work and
provides an acceptable degree of quality assurance.
However, we are fully aware that users of Ubuntu's stable releases
expect, as befits their designation, a high degree of stability. Any
regressions may be extremely disruptive; even relatively innocuous
changes may cause problems if they break known and deployed workarounds;
and experience has taught us to expect the unexpected at all times. The
best way to maintain stability is simply not to make any changes. Thus
we require that updates are not only believed to be safe, but also that
the rationale for each update includes benefits that outweigh the risks
of making '''any''' change rather than simply leaving the package alone.
There are a variety of special cases where examination indicates that
not changing the operating system is not in fact a guarantee of
stability:
* The set of hardware deployed in the field is liable to frequent
change, and thus it has been necessary to update stable releases with
improvements to hardware support: the Linux kernel and the `hal-info`
package have been updated for this reason.
* The Ubuntu archive contains references to some packages that are not
part of the Ubuntu archive, to make them easier to find; these
references need to be updated when external archives change. The
`app-install-data-partner` package has been updated for this reason.
* Any computer system is subject to external events that cannot be
ignored, such as changes in daylight savings time imposed by local
legislation. The `tzdata` package has been updated for this reason.
* Software that interacts with external servers forms part of a larger
system, only part of which can be controlled by Ubuntu's update
policies. When the server changes, it is no longer obvious that
stasis guarantees stability. Packages such as MSN or ICQ clients have
been updated for this reason.
The general thread running through these special cases is that we
contemplate updates when the external environment changes in ways that
have a significant effect on Ubuntu packages. The Landscape client, as
part of a system where administrative actions are reasonably expected to
be applicable in parallel to disparate client systems, is such a case.
As such, the Technical Board '''approves''' the proposed policy [1],
with specific cases at the discretion of the ubuntu-sru team.
== Criteria for other similar cases ==
The Technical Board reserves discretion to consider similar requests for
updates and approve or decline them, and it is not our intention to open
the floodgates to general updates of all packages in Ubuntu's stable
releases to new upstream versions; we believe that in general this would
be to the detriment of stability, and would cause serious problems for
Ubuntu developers and testers who would be faced with a combinatorial
explosion in terms of the packages they need to track.
However, the rationale above suggests some criteria which might be
applied to similar cases in future:
* Updates to new upstream versions of packages must be '''forced or
substantially impelled by changes in the external environment'''.
Changes internal to the operating system we ship (i.e. the Ubuntu
archive), or simple bugs or new features, would not normally qualify.
The changes must be outside anything that could reasonably be
encapsulated in a stable release of Ubuntu.
* A new upstream version must be the '''best way to solve the
problem'''. For example, if a new upstream version includes a small
protocol compatibility fix and a large set of user interface changes,
then, without any judgement required as to the benefits of the user
interface changes, we will normally prefer to backport the protocol
compatibility fix to the version currently in Ubuntu.
* The upstream developers must be '''willing to work with Ubuntu'''. A
responsive upstream who understands Ubuntu's requirements and is
willing to work within them can make things very much easier for us.
* The upstream code must be '''well-tested''' (in terms of unit and
system tests), and it must be straightforward to run those tests on
the actual packages proposed for deployment to Ubuntu users.
* Where possible, the package must have '''minimal interaction with
other packages in Ubuntu'''. Ensuring that there are no regressions
in a library package that requires changes in several of its
reverse-dependencies, for example, is significantly harder than
ensuring that there are no regressions in a package with a
straightforward standalone interface that can simply be tested in
isolation. We would not normally accept the former, but might
consider the latter.
== References ==
1. Landscape updates policy:
https://wiki.ubuntu.com/LandscapeUpdates
2. Landscape client PPA:
https://launchpad.net/~landscape/+archive/ppa
3. Technical Board meeting log, 2009-02-24:
http://irclogs.ubuntu.com/2009/02/24/%23ubuntu-meeting.html
--
Colin Watson [cjwat...@ubuntu.com]
signature.asc
Description: Digital signature
-- ubuntu-devel-announce mailing list ubuntu-devel-announce@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
