Hi,

If I were being generous to myself, I could claim that I do uploads of backports
versions hot on the heels of the unstable version because I was trying to see if
dgit or tag2upload might manage to handle the situation, but actually it's just
me being stupid.

Having done it in the past (with dgit), I've had rejection mails saying something like:

  Backported version is not available in testing -- No upgrade path to forky

which is fair enough.  (However, it is possible I only got that mail because that package
was going through NEW or somesuch, so maybe there was manual intervention going on.  Could i so perhaps it's normal for such
premature uploads to be silently dropped?)

Recently I did the same thing, using git-debpush, with:

  os-autoinst debian/5.1764330105.c5cfd48b-1_bpo13+1

It ran without complaint, and I received no mail about it not being accepted ...
however, it never made it to trixie-backports.

I see that it's visible here though:

https://browse.dgit.debian.org/os-autoinst.git/tag/?h=debian/5.1764330105.c5cfd48b-1_bpo13%2b1

Finally: what is this bug actually about:

  a) It would be nice if there were some way of uploading to backports in a way
     that would put the upload on hold until the migration to testing happens --
     I've no idea if tag2upload can help with that.

  b) Failing that, it would be nice if git-debpush and/or dgit would check if
     there there is a more up-to-date version in testing before allowing an
     upload to backports.

  c) If it is the case that there is something about tag2upload uploads that is
     preventing one being informed that an upload has been rejected on this
     basis (or any other basis for that matter), that should probably be fixed.

Cheers, Phil.

Hello,

It would have to be opt-in, because sometimes it is legitimate to skip
waiting for migration, such as in the case of a security fix.

If we thought it was worth it we could have an additional piece of tag
metadata to implement some kind of DELAYED queue for tag2upload.
That would mean Debian having two separate DELAYED queues, though, which
could be confusing.

This is the "os-autoinst debian/5.1764330105.c5cfd48b-1_bpo13+1" upload,
right?

It looks like dak decided to silently reject that, because I don't see
any mail from dak to <debian-tag2upload@lists.d.o>.  I would guess that
it is a bug in dak's handling of tag2upload uploads.  I don't think
there is any reason to think there is a bug at the tag2upload end.