Bug#986904: blag-fortune/1.5.0-1 [ITA] -- anarchist quotes for fortune
On Sat, Jun 05, 2021 at 01:45:38PM +0000, tous wrote:
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Friday, May 28, 2021 5:49 PM, Tobias Frost <tobi@sviech.de> wrote:
>
> > Hi tous,
> >
> > Thanks for adopting the package!
>
> Hi toby,
>
> I'm glad you are willing to sponsor the blag-fortune package :)
>
> >
> > - You've put the package on salsa! that's great, but I've been burnt with private namespaces, so
> > I discourage them. Would you mind to put it into the debian namespace? (I'd create it for you and
> > give you all required rights)
>
> Not at all, please do this.
Done. Let me know if there are issues with access right or so and please update d/control accordingly.
> >
> > - d/copyright has an empty Upstream-Contact field. Please either fill or remove.
> > - As there is no dep3 header on the patch… Please add one and consider upstreaming the patch.
> >
> > Those are only small things and should be easy to fix. Please confirm that you want to target unstable
> > and I can do the upload. (Remove the moreinfo tag when ready)
> >
> > --
> > Cheers,
> > tobi
> >
>
> I uploaded to https://mentors.debian.net/package/blag-fortune/ the package
> containing the fixes for the issues that you pointed out. I would like to
> solve #900647 but I don't know the properly way solve this bug at moment.
> Would upload to unstable could cause any trouble to fix this bug in the
> future?
Uploading to unstable during the freeze can cause troubles _if_ the version
currently in testing becomes suddendly RC-buggy… In this case you will need to
revert this upload and provide an minimal, targeted fix for the hypthetical
problem in testing. That is usually a bit nasty and because of that an upload
to unstable should be avoided.
Minimal means that no other changes beside the fix are allowed.
#900647: The bug asks for an rename of the package; that requires a travel
through the NEW queue. It does not matter whether it is cleared using
experimental or using unstable. Now, if you would need to react quickly because
of that hypothical "became RC buggy" scenario, and had already cleared NEW, you
would have to revert the change and because of that _possibly_* need another
trip through NEW.
Whether you upload to experimental or unstable will not impact your ability
to fix that bug at all.
TL;DR: If you want to play it safe, go experimental. Otherwise there is a slim
change that bullseye will be released without your package; if you say, danger
is my second name, let me know and I'll accept your wish for unstable.
* this is quite a interesting corner case: reintroducing an old binary package…
I assume that this requires a NEW cleaing; but as I never saw this RIL, can be
wrong here.
Reply to: