[MIR] golang-github-azure-azure-sdk-for-go-dev

[Nicholas Skaggs]

[Availability]
Source-only package currently available in universe.

[Rationale]
Build-dependency for juju. This is part of our on-going work for bug 1508120, to stop bundling our dependencies in our source package.

[Security]
This is a source package which will only be used by other Go projects that build-depend on it.
Standard practices in the Go ecosystem unfortunately is not to do any release/tag, nor publish changelogs, bugfix announcements or other advisory information.
Most of those projects will therefore have a 0.0+git-hash kind of version scheme for their packaged form.
Update to those will typically be a completely new snapshot and refresh of their downstreams to match or be a one-off cherry-pick after a specific issue is reported.

[Quality assurance]
Source-only, arch:all package.
There are currently no bug reports filed against this source package.
The package is either maintained in Debian or maintained by its upstream directly in Ubuntu.
Most of those packages do not have a debian/watch file due to their upstream never pushing out versioned releases.

[Dependencies]
We are only interested in the -dev source-only package. None of those have build-dependencies due to being source-only.

[Maintenance]
This package already has a maintainer, and exists in the archive already. As with the other juju packages, the ubuntu-server team will provide ownership. However, the Juju QA team has also been subscribed to all bug mails for this package, and all others which we are requesting promotion into main as part of of work on bug 1508120 in order to ensure a smooth transition.

[Background information]
These MIRs are being filed in support of the ongoing work on bug 1508120, at the behest of the Security team, and the FFe for juju-core's inclusion in main for xenial, bug 1545913.

Note, the juju package will continue to bundle this dependency for trusty and older release, due to lack of go support and resources to backport and maintain these dependencies in trusty. However, these dependencies are used for all new builds, and have priority whenever present. This is in-line with the security team's recommendations and agreement as part of bug 1508120.

[Steve Langasek (vorlon)]

Currently, the team subscriber for juju-core and juju-mongodb is ubuntu-server (cf. http://reqorts.qa.ubuntu.com/reports/m-r-package-team-mapping.html). Should they be the team subscriber for these newly-MIRed packages as well, or will the juju team be directly responsible for them in the archive and should therefore be added to the list of teams for main?

[Nicholas Skaggs (nskaggs)]

@vorlon, yes you are correct, nothing is changing on that front. I've simply added the juju-qa team as well so we can also keep an eye on things during this process.

[Michael Terry (mterry)]

- Same subscriber issue Steve noticed
- Needs MIR for golang-github-azure-go-pkcs12-dev and golang-github-azure-go-autorest-dev
- I'm not excited about the test skips in debian/rules:

 # core/http_test and core/http/httputil don't compile properly
 # storage needs "ACCOUNT_NAME" to test against remote services
 DH_GOLANG_EXCLUDES='core/http core/tls storage' dh_auto_test

In storage, I'd rather we just patched storage/client_test.go to use c.Skip instead of c.Fatal for its error about ACCOUNT_NAME. That way we can test the other tests in storage/ that don't require ACCOUNT_NAME (and any new added tests in future in that subdir).

Likewise, I'm nervous about the solution to core/tls test failures being just skipping them. The failure is because this package is shipping a fork of core/tls, which is never super great. In this case, they are doing so because of https://github.com/golang/go/issues/5742 which means golang's copy can't deal with Azure. So OK, they have a good reason. But I'm not pumped with our solution to outdated forked code being, "let's just stop running tests."

Can we investigate whether the test failure indicates a real problem / how much work an updated core/tls is / whether we can skip specific tests rather than the entire core/tls subdirectory?

Likewise, what's the story with core/http? Its test code doesn't compile apparently. Do we know why? And are we shipping a forked copy for the same reason as above or something else?

[Launchpad Janitor (janitor)]

[Expired for golang-github-azure-azure-sdk-for-go (Ubuntu) because there has been no activity for 60 days.]