On Wed, Mar 21, 2018 at 08:53:20PM -0700, Steve Langasek wrote: > Particularly for a case of an autopkgtest that has regressed via > security/SRU, I think it matters to clean these up, as not doing so means we > lose any information about whether *other* SRUs are causing user-affecting > regressions in that package. > > Bundling the autopkgtest fix with the next SRU of dovecot doesn't provide > this protection, because the next SRU of systemd (for example) could break > dovecot without us noticing because of the ignored already-failing > autopkgtests.
One thought I've had on this. It seems to me that this is a symptom of bundling dep8 tests inside source packages themselves. We are unable to update the test without updating the payload. What if we could? How hard would this be: 1) Have somewhere where uploaders can place "pending" dep8 updates. 2) Adjust infrastucture to use such a place if updates exist there over the package source itself. 3) Block uploads that do not supersede dep8 tests in this location (to ensure that they correctly integrate pending updates). Here's a more concrete implementation detail proposal: 1) Define the place to put pending "live" dep8 updates as a branch called "dep8/<release>" against the target package in a git repository owned by ~ubuntu-sru. (version_string escaped according to the rules defined in dep14). 2) Adjust infrastructure to use that location in favour of debian/tests/ if it exists. 3) Adjust sru-review to warn if a branch matching "dep8/<release>" exists in ~ubuntu-sru. In this case the SRU reviewer will need to check that the contents of that branch is correctly incorporated before archiving the branch and accepting the SRU. I'm not sure how test updates would work for dep8 tests not in debian/tests, such as the Ruby stuff. Other test updates might need non-test changes, and I don't know about those either. I'm not proposing to necessarily do this work right. Just an idea. Possibly for a backlog somewhere. Robie
signature.asc
Description: PGP signature
-- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
