ci.d.n direct access to experimental ?

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

I am currently trying to debug (work around) a problem (races in
gnupg2 startup) which occurs in ci.debian.net, but which is hard to
reproduce.  I have a problem with my workflow, which is:

 1. Look at some logs to decide what seems to be going wrong,
    and what information might help shine a light on things, and
    what workaround approach(es) might help.

 2. Implement the above.  Test them locally to check that nothing
    unexpected breaks and that the output is as intended.

 3. Upload to experimental.

 4. Wait ???? hours (2-8 hours?) for deb.debian.net to have the
    updated package.

 5. Trigger a retest using the ci.d.n API.

 6. Wait ?? (an hour or two?) for my test job to get to the had of the
    ci.d.n queue, and actually run and produce output on the ci.d.n
    web pages.

 7. See if I waited long enough in step 4, by observing the version
    ci.d.n said it tested.  If not, wait ????? some more ????
    and then goto step 5.

 8. Goto step 1.

Step 4 is the killer here.  Not only is the delay very long; it is
also undocumented and unpredictable, and seems to vary depending on
one's vantage point.  So the package might look fine to me but ci.d.n
might get the old version - see step 7.

Could ci.d.n be granted some more direct access to the archive, and
use it (for experimental at least) ?

I also wonder whether this effect might also cause ci.d.n to sometimes
test the wrong thing when asked to do so by Britney.

Thanks,
Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.