Ian Jackson <[email protected]> writes: > Sean Whitton writes ("Bug#1123680: git-debpush: support for DELAYED queue?"): >> On Fri 19 Dec 2025 at 09:35pm +01, Simon Josefsson wrote: >> > I can't find any occurance of the "delay" keyword in the git-debpush >> > manpage or on https://wiki.debian.org/tag2upload -- is uploading to the >> > DELAYED queue supported via tag2upload? How do I do that? >> >> It's not supported. I don't think it would be too difficult, because >> dgit already supports it. We would just have to plumb tag metadata >> through. If someone wanted to work on it might even be a good bug for a >> new contributor to dgit/tag2upload. > > I think this is much more complicated than it seems. > > Firstly, I want to say that while DELAYED serves a vital purpose in > Debian's internal political economy, its actual design and protocol > structure is very strange and has many undesirable properties. The > invisibility-to-others of a DELAYED upload is particularly poor. > There is much opportunity for people stepping on each others' feet. > > In an ideal world, we would perhaps invent something a bit like > DELAYED but much more git-like. IDK exactly what the shape would be. > It would be worth thinking about this before we implement something in > tag2upload. Or to put it another way: we should decide what a > pure-git DELAYED NMU looks like, first. I doubt it would involve the > legacy archive queue daemon DELAYED feature. > > Secondly, there is a practical difficulty. DELAYED is only sensible > for an NMU. But we don't support NMUs properly because we don't have > anywhere to push the tag.
I agree that this may be one of those things that are not worth
supporting because they are not the best workflows to start with.
So I would suggest delaying/deferring support for this for as long as
possible.
I believe DELAYED is sensible for other things than NMU's though. My
use-case for the 'xe' DELAYED upload was the ITS/PackageSalvaging
process. That entire process seems to also be a workaround for some
other deeper problem.
One solution to this could be declare the following as the tag2upload
DELAYED process:
1) Do a normal pre-dgit upload to DELAYED following all normal
process around that (using old 'debsign+dput' tooling), increasing
the intended delay by one day, and then one day before the
cut-off, do
2) cancel the DELAYED upload and make a tag2upload upload.
This is technically not pretty, but I think it pretty much mirror the
social aspects of what DELAYED is intenteded to capture, which seems to
be what it is all about.
/Simon
signature.asc
Description: PGP signature
