Re: RFS/package review
On Wed, Jun 9, 2021 at 11:32 PM Jonas Meurer <mejo@debian.org> 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
Reply to: