Control: tag -1 -moreinfo Dear Gianfranco, Thanks for your detailed explanation! On Wed, 19 Apr 2017 12:39:00 +0000 (UTC) Gianfranco Costamagna <locutusofborg@debian.org> wrote: > 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. Yes, I only ever fixed 3-4 RC bugs, so not very experienced at this, and giving rough estimation how hard to solve a trivial or non-trivial issue. However, now I understand using t-p-u is not only requiring manual operation from release team, but also risky because we are unable to let mass unstable users to test the version for a few days and become confident to let it migrate to testing. > 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). Reasonable. Now think this is the most difficult part because it's more about "feeling", than rules. Such as: - Feeling of confidence that fixing RC and not making new RC - Feeling of deserving the cost of brothering release team - Feeling of avoiding troubles and keep risk minimal etc. Seems I need more experience so I can have the right feeling. > 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. Yes, speaking of library, it always need more attention. Your example is quite convincing. Thanks! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Attachment:
pgpJ9P2PzbDQ_.pgp
Description: PGP signature