Document testing of new devstack features
At the Boston 2017 Summit I had mentioned that the pattern of using non
voting/experimental jobs was not working for getting new features into
Devstack. It is slow and leads people to being too conservative when it
comes to pushing new things in. Instead I suggested that since Devstack
changes are self testing we add the features, have change that enables
the feature, and if that changes passes we move forward with merging
(assuming code review is fine and necessary communication is done).
Document this process in the HACKING file so that we have something we
can point to when people want to add a new experimental job for every
new little thing (ipv6, tls, systemd, etc).
Change-Id: I5190cc3d3de4e81d52748347306133b5034d5531
1 file changed