Doko, I just noticed your comment about dep8 tests. I agree that some sort of mechanism to avoid ftbfs would be good. Though in this respect, golang isn't so different than C libraries, where an unexpected API update or library bug can cause ftbfs in reverse-depends. We use dep8 tests as best practices to avoid that, but don't *require* it as part of a MIR.
But actually, I expected we could use Built-Using fields in our proposed-migration tooling to automatically test that reverse-depends could still build. Is that not in the works yet?
That seems more packaging-friendly than requiring a bunch of one-line dep8 tests to trigger a rebuild test. Especially if we have to add a delta to get it.
Doko, I just noticed your comment about dep8 tests. I agree that some sort of mechanism to avoid ftbfs would be good. Though in this respect, golang isn't so different than C libraries, where an unexpected API update or library bug can cause ftbfs in reverse-depends. We use dep8 tests as best practices to avoid that, but don't *require* it as part of a MIR.
But actually, I expected we could use Built-Using fields in our proposed-migration tooling to automatically test that reverse-depends could still build. Is that not in the works yet?
That seems more packaging-friendly than requiring a bunch of one-line dep8 tests to trigger a rebuild test. Especially if we have to add a delta to get it.