Release policy proposal from London Tier2
=========================================
In an attempt to put some structure into the general dissatisfaction,
we tried to categorise upgrades into 3 types:
1: security critical. Ie. patches that cover vulnerabilities (not CA
upgrades). These, by nature, can be announced with no warning and
the expectation that sites will upgrade as soon as possible. It was
noted, however, that even then it may be a problem for sites to do
this instantaneously, as relevant staff may be unavailable. If
considered sufficiently serious the failure to upgrade could
reasonably lead to the site having to be banned/taken offline until
the upgrade took place.
2: minor upgrades. Defined as upgrades that involve essentially well
packaged, automated tasks (no more than a few rpm changes and a
configuration script). The CA rpm upgrade would be an example.
These could be released with little/no warning and could reasonably
be expected to be implemented within 3 weeks (to take into account
the worst case of staff unavailability).
3: major upgrades. Any upgrade involving, for example, new service
nodes, kernel or OS changes, reinstallation of any nodes, firewall
changes. All these changes may need significant amount of time to
schedule. It was felt that:
(a) there should be no more than 2 such upgrades within any 12 month period;
(b) Such an upgrade could only be reasonably expected to be completed in 3
months of the announcement of the upgrade (one site actually felt 6
months was a more appropriate figure);
(c) if a new major upgrade was announced less than 6 months after the
previous major upgrade, a site should not be reasonably expected to
upgrade in less that 9 months from the announcement of the first
upgrade (ie. any earlier than if the upgrade had been announced 6
months after the previous upgrade) or else the site should be allowed
to skip an upgrade altogether;
(d) in the event that sites were allowed to skip an upgrade, any security
critical updates must be release for earlier releases as well (ie.
the release of a security or minor upgrade cannot be used as a way of
forcing sites not to skip a major upgrade);
(e) there was also some support for the idea that major upgrades could
only be scheduled at particular dates in the year (such as a potential
date for a spring/summer/autumn/winter release). However, if 4 such
dates were decided this would not change (a) or (c) ie. only half such
potential release dates should be actual release dates.
Last modified Fri 10 December 2004 . View page history
Switch to HTTPS . Website Help . Print View . Built with GridSite 1.4.3
=========================================
In an attempt to put some structure into the general dissatisfaction,
we tried to categorise upgrades into 3 types:
1: security critical. Ie. patches that cover vulnerabilities (not CA
upgrades). These, by nature, can be announced with no warning and
the expectation that sites will upgrade as soon as possible. It was
noted, however, that even then it may be a problem for sites to do
this instantaneously, as relevant staff may be unavailable. If
considered sufficiently serious the failure to upgrade could
reasonably lead to the site having to be banned/taken offline until
the upgrade took place.
2: minor upgrades. Defined as upgrades that involve essentially well
packaged, automated tasks (no more than a few rpm changes and a
configuration script). The CA rpm upgrade would be an example.
These could be released with little/no warning and could reasonably
be expected to be implemented within 3 weeks (to take into account
the worst case of staff unavailability).
3: major upgrades. Any upgrade involving, for example, new service
nodes, kernel or OS changes, reinstallation of any nodes, firewall
changes. All these changes may need significant amount of time to
schedule. It was felt that:
(a) there should be no more than 2 such upgrades within any 12 month period;
(b) Such an upgrade could only be reasonably expected to be completed in 3
months of the announcement of the upgrade (one site actually felt 6
months was a more appropriate figure);
(c) if a new major upgrade was announced less than 6 months after the
previous major upgrade, a site should not be reasonably expected to
upgrade in less that 9 months from the announcement of the first
upgrade (ie. any earlier than if the upgrade had been announced 6
months after the previous upgrade) or else the site should be allowed
to skip an upgrade altogether;
(d) in the event that sites were allowed to skip an upgrade, any security
critical updates must be release for earlier releases as well (ie.
the release of a security or minor upgrade cannot be used as a way of
forcing sites not to skip a major upgrade);
(e) there was also some support for the idea that major upgrades could
only be scheduled at particular dates in the year (such as a potential
date for a spring/summer/autumn/winter release). However, if 4 such
dates were decided this would not change (a) or (c) ie. only half such
potential release dates should be actual release dates.
Last modified Fri 10 December 2004 . View page history
Switch to HTTPS . Website Help . Print View . Built with GridSite 1.4.3