My primary concern which isn't really governance would be around making sure the components in `networking-calico` are kept in-sync with the parent classes it inherits from Neutron itself. Is there a plan to keep these in-sync together going forward?

Thanks for this question. I think the answer is that it will be a planned effort, from now on, for us to support new OpenStack versions. From Kilo through to Rocky we have aimed (and managed, so far as I know) to maintain a unified networking-calico codebase that works with all of those versions. However our code does not support Python 3, and OpenStack master now requires Python 3, so we have to invest work in order to have even the possibility of working with Train and later. More generally, it has been frustrating, over the last 2 years or so, to track OpenStack master as the CI requires, because breaking changes (in other OpenStack code) are made frequently and we get hit by them when trying to fix or enhance something (typically unrelated) in networking-calico.

I don't know the history here around `calico-dhcp-agent` but has there been previous efforts to propose integrating the changes made to it into `neutron-dhcp-agent`? It seems the best solution would be to make the functionality provided by the former into the latter rather than relying on parent classes from the former. I suspect there are details here on why that might be difficult but it seems solving that would be helpful in the long-term.