On Wed, 19 Apr 2017 07:01:56 +0000 (UTC) Gianfranco Costamagna <locutusofborg@debian.org> wrote: > Hello, > > >Secondly, testing-proposed-updates is highly inconvenient for the > >release team. It requires manual intervention and slows everything > >down. So we shouldn't upload to unstable unless we *expect* it to be > >unblocked. > > > also, TPU means that semi-automatic bug reports (e.g. piuparts, ftbfs and so on) > won't be opened in case the package has problems. > Uploading to unstable an RC fix means higher probability of a fix being tested. > > I don't even remember if t-p-u is available as external repo Targeting t-p-u need pre-approval from release team, while targeting unstable doesn't. 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 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. Thank you! -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Attachment:
pgpgfP0euGCcc.pgp
Description: PGP signature