On Wed, Jun 9, 2021 at 11:32 PM Jonas Meurer <[email protected]> wrote: > > Hi Nilesh :) > > Nilesh Patra wrote: > >> Peymaneh Nejad wrote: > >>>> If you are using sbuild, you can build locally with a --extra-package > >>>> option > >>>> > >>>>> It depends on a newer version of golang-github-klauspost-cpuid-dev than > >>>>> is > >>>>> in the repos. I did a fork of the package > >>>>> (https://salsa.debian.org/peymaneh/golang-github-klauspost-cpuid) for > >>>>> testing until the issue is resolved > >>>>> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989624) > >>>>> Changelogs have set distribution=experimental. > >>>> > >>>> Consider doing similar changes for this one (with d/experimental branch > >>>> along with a mail to > >>>> maintainer) as I suggested to do it for > >>>> golang-github-masterminds-semver-dev in my other mail > >>> > >>> Okay. > >> > >> Quick comment here: wouldn't it be more straight-forward to simply ping > >> the maintainer(s) of the packages in question first and ask for permission > >> to upload a newer upstream release? That way, an extra upload to > >> experimental could be avoided. > > > > By "upload a newer upstream release" do you mean an "upload to unstable"? > > > > If that is what you mean, then: > > > > Sure, but at the moment we are in deep freeze so new versions of existing > > packages should be avoided right? > > Upload from 1.3.1 -> 2.0.6 is a major bump. > > I'd want to avoid such changes at the moment. > > > > One option is that we upload to unstable and it gets blocked by the freeze > > team, > > but suppose some package depending on golang-github-klauspost-cpuid has a > > bug, and new upload is done for it, > > it'll rebuild with new version of klauspost-cpuid. Something similar > > happened in the med-team with orthanc package recently, and it > > became a bit of a mess to fix it. > > Sure, you're right about the release process. I totally forgot about > that. So indeed let's go with uploading packages to experimental for now > and push the packages to unstable as soon as Bullseye is released :) >
Please be sure you have tested the reverse dependencies when a package's major version is bumped, it usually means breaking changes in its public interface. It's just like library transition but not like the normal one we do for C libraries. People here usually test it with ratt[1] which is written for this purpose. [1] http://tracker.debian.org/pkg/ratt -- Shengjing Zhu
