Hi,
On Mon, Feb 28, 2011 at 09:36:30PM +0900, Osamu Aoki wrote:
> stable-proposed-updates is defined as:
> http://www.debian.org/doc/developers-reference/pkgs.html#upload-stable
> A) a truly critical functionality problem
> B) the package becomes uninstallable
> C) a released architecture lacks the package
>
> stable-updates is defined as:
> http://lists.debian.org/debian-volatile-announce/2011/msg00000.html
> D) The update is urgent and not of a security nature. Security updates
> will continue to be pushed through the security archive. Examples
> include packages broken by the flow of time (c.f. spamassassin and
> the year 2010 problem) and fixes for bugs introduced by point
> releases.
> E) The package in question is a data package and the data must be updated
> in a timely manner (e.g. tzdata).
> F) Fixes to leaf packages that were broken by external changes (e.g.
> video downloading tools and tor).
> G) Packages that need to be current to be useful (e.g. clamav).
>
> Here, I think A includes (D + E + G) in some way. F is relaxing of A
> qualification rule for leaf packages. Are we removing A from
> stable-proposed-updates? Basically stable-updates seems to be A with
> relaxed qualification to be "critical functionality problem" but with
> limitted applicable package types?
every package will enter stable-proposed-updates first. Then, if it warrants
an update outside of the normal point release cycle (and those are rare) it
gets copied to squeeze-updates for public consumption.
Transitively the rules for stable-proposed-updates got a bit more relaxed
to fix up packages and keep them useful in stable if they're broken by
outside influences not under our control.[*] Previously those were updated
through volatile. Now they'll be fixed in stable instead if the fixes
are self-contained and unlikely to cause any breakage in other packages.
(Thus the reference to leaf packages.)
I hope that clears it up.
Kind regards
Philipp Kern
[*] Release files are indeed under "our" control, so checksum fixes
wouldn't qualify per se (but there might be reasons to do them anyway).
Protocol changes in proprietary messengers that require an update would
qualify, though.
Attachment:
signature.asc
Description: Digital signature