openstack/devstack
Code Issues Proposed changes

Document testing of new devstack features

Browse Source 
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
This commit is contained in:
Clark Boylan 2017-05-12 10:16:33 -07:00
parent 27df725179
commit 2a6112ea9a
1 changed files with 24 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
HACKING.rst
View File

@ -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.