SRUs solely for dep8 updates

[Robie Basak]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20180327/ced0a9ea/attachment.sig>