Are there any objections to starting the process of uploading packages to unstable, following the outline that Reinhard provided (quoted at the end of the message)? I'm here at DebCamp and would be happy to start working through the uploads and any other hand-holding to get the migration underway.
I know we've got an item on the BoF to discuss this, but maybe by next week we could have a status update of how things are going? I've spend some time today checking things in experimental and building a few other packages against those versions, and at least from what I have testing things appear to be working OK with the newer versions. Mathias On Sat, 2024-07-13 at 20:48 -0400, Reinhard Tartler wrote: > 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
signature.asc
Description: This is a digitally signed message part