Work on this is at an advanced stage. Deployment plan:
Stage I - client deployment (best effort config, to sid) 1. Get a branch that I'm happy with, and which has new test cases for the local detection of tainting, and which passes all the tests for every commit, locally. This version will call the new service on a best effort basis, and not mind if it errors out because the server can't dispatch the new query. (Client config is "unknown" support for all distros.) 2. Do a live test upload of dgit-test-dummy, with the above version of dgit. 3. Push the new dgit to salsa, and upload it. Block testing migration with a bug. 4. Wait for the autobuilders to build the .deb, and for the ci.d.n autopkgtests to report. Stage II - server deployment 5. Deploy the server side to the dgit repos. 6. Do live test uploads of dgit-test-dummy with versions of dgit from testing and unstable. Stage III - client deployment (mandatory config, to testing) 7. Prepare a dgit version which expects that the Debian server implements the new protocol and fails when it doesn't. (Client config change to "true" for the "debian" distro.) This version should close the holding bug, and also this bug. 8. Locally test every commit as usual. 9. Do a live test upload of dgit-test-dummy with this dgit version. 10. Upload the new dgit version. Stage IV Monitor the results. Maybe write a blog post about the conservation of integers. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
