From 2a6112ea9ab698714c6b4e92ddb829e2d4574a7c Mon Sep 17 00:00:00 2001 From: Clark Boylan Date: Fri, 12 May 2017 10:16:33 -0700 Subject: [PATCH] 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 --- HACKING.rst | 25 ++++++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/HACKING.rst b/HACKING.rst index b76cb6c4a7..fc67f09a7b 100644 --- a/HACKING.rst +++ b/HACKING.rst @@ -322,7 +322,7 @@ Variables and Functions Review Criteria -=============== +--------------- There are some broad criteria that will be followed when reviewing your change @@ -364,3 +364,26 @@ your change * **Reviewers** -- please see ``MAINTAINERS.rst`` for a list of people that should be added to reviews of various sub-systems. + + +Making Changes, Testing, and CI +------------------------------- + +Changes to Devstack are tested by automated continuous integration jobs +that run on a variety of Linux Distros using a handful of common +configurations. What this means is that every change to Devstack is +self testing. One major benefit of this is that developers do not +typically need to add new non voting test jobs to add features to +Devstack. Instead the features can be added, then if testing passes +with the feature enabled the change is ready to merge (pending code +review). + +A concrete example of this was the switch from screen based service +management to systemd based service management. No new jobs were +created for this. Instead the features were added to devstack, tested +locally and in CI using a change that enabled the feature, then once +the enabling change was passing and the new behavior communicated and +documented it was merged. + +Using this process has been proven to be effective and leads to +quicker implementation of desired features.