On Mon, May 11, 2020 at 8:52 PM teor <t...@riseup.net> wrote: > > Hi Nick, > > > On 12 May 2020, at 06:48, Nick Mathewson <ni...@torproject.org> wrote: > > > > ## Migration steps > > > > First, we implement all of the above, but set it to be disabled by > > default. We use torrc fields to selectively enable them for testing > > purposes, to make sure they work. > > Can you expand on the testing plan here? > > One of the risks with multi-year migration projects is that unrelated > changes break the migration, and we don't notice. > > For example, you might need to create a chutney network for each > stage, and run them on every pull request and merge. In our current > CI, that's 30-60 seconds of extra time per network, or 2-4 extra > minutes of CI time. > > If you need to test different combinations of features for each stage, > let's try to do that in the same networks. Otherwise, the testing matrix > expands out very quickly.
I agree here think that the right approach here is to test for the various ways that we expect the network to exist at a time. The trickiest stage of the migration will be the one where some services support ntor keys and some don't, some clients do and some don't. If we add a chutney network for that case specifically and make sure that all clients can reach all services, we should be fine here. _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev