Re: A change to how calm expires packages

[Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>]

On 2022-01-20 07:33, Jon Turney wrote:
> To try to avoid packages lingering in the 'test' status indefinitely 
> (which leads to them not being installed by most users, as they don't 
> run setup with 'consider test packages' enabled, thus these packages 
> generally aren't getting used, so having them isn't generating much 
> value), I'm planning to change how calm expires packages:
> 
> Currently (in the absence of configuration otherwise [1]), calm will 
> retain up to 3 non-test versions, and 3 test versions, and expire all 
> other versions.
> 
> I plan to change this to also expire test versions which are superseded 
> by a non-test version (that is: expire test versions where a non-test 
> version with a higher version number exists).
> 
> I believe this makes the default behaviour closer to what package 
> maintainers are likely to want to happen.
> 
> This change will cause the following packages to be removed:
> 
> grep-3.6-1
> grep-3.7-1
> gzip-1.10-1
> readline-8.1-1
> 
> Brian,
> 
> The only packages I can see where this seems like it will do the wrong 
> thing are listed below.  Before deploying this, would you like me to:?
> 
> grep: untest 3.6-1 and expire 3.0.1
> gzip: untest 1.10-1 and expire 1.7-2

Your calm expiry actions seem to DTRT, but your suggestions are probably 
a better approach, so yes please do so!

Test releases grep 3.6 and gzip 1.10 successors grep 3.7 and gzip 1.11 
were released during the test period, both including bug fixes, later 
promoted to current.
A new grep 3.7 test was released, as the changes were significant: high 
impact and pervasive, with only 9 months between releases.
The gzip 1.11 changes were not: mainly docs, help, infra, typos, 
warnings, and other platforms, despite 2 years 9 months between releases 
and more commits.
I was unaware of *untest*, so bumped the grep release and gzip version 
for current.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]