Re: Coordingating/planning various golang transitions

On Sat, Jul 13, 2024 at 2:57 PM Simon Josefsson <simon@josefsson.org> wrote:

Reinhard Tartler <siretart@gmail.com> writes:

> My takeaway is that we need to update a large number of packages at the
> same time, starting with src:golang-google-genproto
> and src:golang-google-grpc. This will unblock a number of packages that are
> currently in experimental, and will allow them to enter unstable. However,
> this comes with the risk of breaking other packages.
>
> I've been chasing down the stack of dependency fairly far, but I feel I'm
> reaching my capacity of how far I'm able to push this transition.

I am suffering from lack of grpc update too (for rekor and cosign), and
I'm available to help do the required work here. Alas, I'm a bit at a
loss how to approach this problem, as whenever I've started to look into
this I reach some kind of circular dependency loop that I don't know how
to resolve. If someone were to do the heavy thinking and maybe make a
list of packages and versions to upload to experimental I am willing to
help :)

I'm really glad to hear that an experienced and active DD like you

is volunteering to help with this migration. That's really much

appreciated.

As far as I can tell, I've managed to execute this transition in "experimental"

for all packages that are currently in testing and are affected by

the containerd migration.

It is possible that I missed packages, so I'd appreciate some double-checking

of my work.

Shouldn't the process really be to take one important package, like
podman, and then go through each reverse dependency that's not already
in unstable and just upload them to experimental? Entering into
dependency loops as it may be, but eventually reaching back to podman.
If some other package stops building with the new reverse dependency,
threat that as a serious bug in that separate package instead of with
the new upload. Maybe we have to live with some failed builds after the
upload to unstable due to circular dependencies, but shouldn't that be
possible to resolve by scheduling a binnmu or simply doing another
upload of the relevant package? I wish some documentation on how to
approach this were available.

That sounds very goal oriented if we agreed on the goal being

"get podman 5 into testing asap". This is clearly one of my goals.

The approach that you describe above comes with risk:

- Does uploading packages that start this transition cause unpleasant surprises?
- Does this break packages that we miss to testbuild?
- Does this slow down other, unrelated ongoing transitions?
- Does this require major upstream version updates to other packages (and if so, are the maintainers of affected packages available to quickly react and help with restoring those packages)?

- Do we need to temporarily remove other packages to ease this migration?

I personally believe the benefits of achieving the goal outweighs the risk. I

do hope the Debian release team agrees and is comfortable with me starting the

migration by uploading packages that are currently in experimental to unstable,

and are able to advise and help with hints to britney to minimize the disruption.

My pitch would be to start with sourceful uploads of (and in that order):

- golang-google-genproto
- golang-google-grpc
- golang-github-grpc-ecosystem-grpc-gateway.v2

- golang-github-google-cel-go
- golang-opentelemetry-otel
- golang-github-googleapis-gnostic
- etcd
- golang-gogottrpc
- golang-github-containerd-btrfs
- golang-github-containerd-go-cni
- golang-github-containerd-go-runc
- golang-github-coreos-bbolt
- golang-github-google-certificate-transparency

- golang-github-lightstep-lightstep-tracer-common
- golang-github-kurin-blazer
- golang-google-cloud
- golang-github-containerd-cgroups

- golang-github-containerd-typeurl
- containerd
- golang-github-cloudflare-cfssl
- rootlesskit
- docker.io
- golang-github-fsouza-go-dockerclient
- golang-github-openshift-imagebuilder
- golang-github-containers-storage
- golang-github-containers-image

- golang-github-containers-common
- golang-github-containers-buildah
- libpod


Yes, that is a long list. I think we can do it, but I'm also

interested in minimizing surprises, smooth transitions, and would like to mititgate

the risks mentioned above with coordination and thinking this through.

Thanks so much for your assistance!

regards,
Reinhard