Re: RFS/package review

[Jonas Meurer]

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.

Kind regards,
 jonas

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 :)

OpenPGP_signature
Description: OpenPGP digital signature