Bug#860466: RFS: equivs/2.0.10 [QA] -- Circumvent Debian package dependencies
Hello Roger,
>Targeting t-p-u need pre-approval from release team, while targeting
>unstable doesn't.
>
true
>I didn't targeting t-p-u. What I meant was if:
>- my upload to unstable don't get unblock permission from release
>team
>- the original version of this package in stretch get a new RC need to
>fix
correct
>When both above two conditions meet, we have to use t-p-u to fix that
>new RC bug, which may be troublesome. But it still have way out.
>That's why I originally targeted unstable.
>
>Since it seems both you insist that experimental is the right place,
>I updated the package, uploaded to DoM & mentors, and pushed to
>branch qa_upload3.
the problem is not the theory, but it is more pratical.
Do you know in advance that an RC bug will be trivial to fix, and the fix will
be sane?
in case a bug is not so trivial, and you are not confident with the fix,
having a 10 days delay for migration, requesting help on lists, and having a broader
testing is better than having a package in t-p-u tested only by a RT member.
Having a new version in unstable, in case of a bad RC bug means the package go out
of testing. Simple as that.
(and avoiding bothering of RT members during freeze times is always a sane idea).
So, to avoid troubles, better safe than sorry :)
(I want to point out this because you are having your nm process, and this is part
of the questions your AM will ask you).
Also, in case you upload a library foo2 in unstable
that has a foo1 in testing, you are preventing fixes of reverse-dependencies from being uploaded
in unstable (because to migrate they should be built against the old version).
so, keeping unstable into a "releasable state" is always the preferred, safer solution.
G.
Reply to: