* Holger Levsen <hol...@layer-acht.org> [250507 17:16]:
On Wed, May 07, 2025 at 02:01:19PM +0200, Chris Hofstaedtler wrote:
I'll also propose another option, lets call it D:
not that it matters much (see below) but I think i had proposed this
on irc earlier :)
Yes, sorry. Option D is "Holger's Option D".
On Wed, May 07, 2025 at 02:39:00PM +0100, Ian Jackson wrote:
Gosh, this is all very complicated.
yes, it is. so thanks for writing this up.
It seems anomalous that we (i) schedule binNMUs on each architecture
separately but (ii) they must all be aligned. This leads to suggest
another option
E. Always schedule rebuilds on all arches, so they all
have identical bdates.
(this may be quite hard or a bad idea for other reasons).
I *believe* this is not done (always) because not all architectures always have
enough capacity...
F. Abolish binNMUs and just do no-change source-only uploads.
tag2upload might make this much easier...
(yes but we don't have that yet.)
Anyway,
yes :)
I think that means Chris's option D would work. I have to say this
addition of +1 second feels like a bodge to me, although I can't
immediately think of a way it would go wrong other than merely
confusing humans. (If we go with this option we should maybe pick a
larger value of 1 - aren't there some filesystems with >1s timestamp
granularity? 2 might be better.)
and now I wonder again why S_D_E plus (offset multiplied by something)
is better than what we have or had, which is a new d/changelog entries
for binNMUs causing an entirely new S_D_E for those binNMUs?!?
The offset is fixed per binNMU.
So:
+b1 gets sdate + 1
+b2 gets sdate + 2
etc
Thus, it is entirely predictable, and as long as the binNMU
revisions are aligned across archs (as they must be), it should
work.
Chris
