Hello, On Thu 31 Jan 2019 at 11:40AM +00, Ian Jackson wrote:
> Sean Whitton writes ("Bug#920970: dgit: should ensure .orig is not in the
> .changes when the .orig is already in DEFERRED"):
>> Hmm. After this, with both the -1 and -2 uploads in DEFERRED, I tried
>> to `dcut cancel` the -1 upload so that I could be sure an ftp-master
>> would not try to review -1 in the interval before -2's DEFERRED timer
>> ran out.
>>
>> This caused queued to delete the .orig.tar, such that, presumably, the
>> -2 would be REJECTed immediately upon its DEFERRED timer elapsing.
>> Nice. I have had to `dcut cancel` the -2 upload too and
>
> What a mess.
>
> Maybe dgit should automatically do the dcut for you. But maybe that
> would mean waiting for the queue daemon to act on the dcut ?
>
> None of this seems particularly straightforward, and the problems stem
> from the strange and organically grown ad-hoc "API" offered by the
> queue daemon.
Right. I don't think it is useful for dgit to try to dcut for you.
It's too complicated, and we don't know the order in which queued will
process things.
Instead it can say "looks like this package is NEW and in deferred;
it is highly recommended that you `dcut cancel` that upload, wait for it
to be processed, then dgit push."
>> ask my sponsee for a -3 changelog entry.
>
> Did you not feel able to add one yourself for something like this ? I
> would have done.
I would have done had I had push access to his git repo. Asking him for
a new changelog entry seemed like less effort for him than telling him
to pull from some random git server of mine (since dgit-repos would not
let him fetch my commit until the package is through NEW..).
--
Sean Whitton
signature.asc
Description: PGP signature
