Re: Are we ready to block on autopkgtest regressions?

Paul Gevers writes ("Are we ready to block on autopkgtest regressions?"): > Three days ago I opened a merge request against brintey2 [1] to > enable britney2 to block migrations that cause regressions in > autopkgtest results in testing. Niels copied it to the IRC channel, > but we saw no reactions

Are we ready to block on autopkgtest regressions?

Dear release team, Three days ago I opened a merge request against brintey2 [1] to enable britney2 to block migrations that cause regressions in autopkgtest results in testing. Niels copied it to the IRC channel, but we saw no reactions so far from other RT members. We were wondering what the opin

Processed: user release.debian....@packages.debian.org, usertagging 909315, tagging 909315 ...

Processing commands for cont...@bugs.debian.org: > user release.debian@packages.debian.org Setting user to release.debian@packages.debian.org (was a...@adam-barratt.org.uk). > usertags 909315 = rm There were no usertags set. Usertags are now: rm. > tags 909315 + stretch Bug #909315 [relea

Processed: reassign 909315 to release.debian.org

Processing commands for cont...@bugs.debian.org: > reassign 909315 release.debian.org Bug #909315 [ftp.debian.org] RM: gitlab/stable -- ROM; open security issues, hard to backport fixes Bug reassigned from package 'ftp.debian.org' to 'release.debian.org'. Ignoring request to alter found versions

Bug#909315: RM: gitlab/stable -- ROM; open security issues, hard to backport fixes

Package: ftp.debian.org Severity: normal X-Debbugs-Cc: debian-release@lists.debian.org We backported some security fixes, but it has become much harder as upstream has diverged a lot. We are trying to provide a newer version via stretch-backports. signature.asc Description: OpenPGP digital sig