Re: A change to how calm expires packages

[Hamish McIntyre-Bhatty <hamishmb@live.co.uk>]

On 20/01/2022 14: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:
> 
> _autorebase-001091-0.1
> cygutils-1.4.16-4
> cygwin-3.3.0-0.1.9814cfd8f693
> cygwin-3.3.0-0.2.6c1f49f83fde
> fontforge-20201107p2-1
> fontforge-20201107p8-1
> gcc-11.2.0-0
> grep-3.6-1
> grep-3.7-1
> gzip-1.10-1
> libftdi1-1.4-1
> libiconv-1.16-1
> meson-0.54.2-3
> mingw64-i686-gcc-11.1.0-0.1
> mingw64-i686-gcc-11.2.0-0
> mingw64-i686-gcc-7.3.0-1
> mingw64-x86_64-gcc-11.1.0-0.1
> mingw64-x86_64-gcc-11.2.0-0.1
> mingw64-x86_64-gcc-7.3.0-1
> openbabel-3.1.1p36-1
> openbabel-3.1.1p36-2
> rdiff-backup-2.0.0-1
> readline-8.1-1
> screen-4.6.2-3
> texlive-collection-latexrecommended-doc-20210118-2
> xorg-server-21.1.0-1
> 
> 
> Brian, Ken,
> 
> 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
> texlive-collection-latexrecommended-doc: untest 20210118-2 and expire 
> 20210118-1
> 
> [1] See https://cygwin.com/packaging-hint-files.html#override.hint.  Not 
> that override.hint files do not apply recursively currently.
> 

This seems like a good change to me, also.