Afif / HPC Team: I’ve been following this thread, but only just joined the list. This seems like a reasonable decision -- the freeze policy doesn’t work for all development patterns -- but I’d like to better understand the impact. It seems to me that this will (1) block all new uploads of singularity-container to testing and (2) block the specific version presently in testing from buster’s migration to stable. Q0: is this correct / am I missing other impacts? Q1: will the current version (2.6.1-1) eventually disappear from testing? Q2: Could one develop and maintain a 3.x/Golang package in unstable and bypass testing directly to buster-backports and stretch-backports-sloppy? Q2 seems like a reasonable approach as (a) the backports page specifically identifies security updates as a reason for skipping testing in the backport workflow and (b) the singularity-container package has been good about releasing the 2.x series stretch-backports and jessie-backports-sloppy (prior to jessie entering LTS). I appreciate the effort and dedication to packaging standards even as Golang/agile development makes it hard. > Done [1]. I hesitated because I was thinking about whether to also request removal from backports. > > regards > Afif Yours, -- Tom Downes Center for Gravitation, Cosmology and Astrophysics |
Attachment:
smime.p7s
Description: S/MIME cryptographic signature