Browse code
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
Clark Boylan authored on 2017/05/13 02:16:33Showing 1 changed files
| ... | ... |
@@ -322,7 +322,7 @@ Variables and Functions |
| 322 | 322 |
|
| 323 | 323 |
|
| 324 | 324 |
Review Criteria |
| 325 |
-=============== |
|
| 325 |
+--------------- |
|
| 326 | 326 |
|
| 327 | 327 |
There are some broad criteria that will be followed when reviewing |
| 328 | 328 |
your change |
| ... | ... |
@@ -364,3 +364,26 @@ your change |
| 364 | 364 |
|
| 365 | 365 |
* **Reviewers** -- please see ``MAINTAINERS.rst`` for a list of people |
| 366 | 366 |
that should be added to reviews of various sub-systems. |
| 367 |
+ |
|
| 368 |
+ |
|
| 369 |
+Making Changes, Testing, and CI |
|
| 370 |
+------------------------------- |
|
| 371 |
+ |
|
| 372 |
+Changes to Devstack are tested by automated continuous integration jobs |
|
| 373 |
+that run on a variety of Linux Distros using a handful of common |
|
| 374 |
+configurations. What this means is that every change to Devstack is |
|
| 375 |
+self testing. One major benefit of this is that developers do not |
|
| 376 |
+typically need to add new non voting test jobs to add features to |
|
| 377 |
+Devstack. Instead the features can be added, then if testing passes |
|
| 378 |
+with the feature enabled the change is ready to merge (pending code |
|
| 379 |
+review). |
|
| 380 |
+ |
|
| 381 |
+A concrete example of this was the switch from screen based service |
|
| 382 |
+management to systemd based service management. No new jobs were |
|
| 383 |
+created for this. Instead the features were added to devstack, tested |
|
| 384 |
+locally and in CI using a change that enabled the feature, then once |
|
| 385 |
+the enabling change was passing and the new behavior communicated and |
|
| 386 |
+documented it was merged. |
|
| 387 |
+ |
|
| 388 |
+Using this process has been proven to be effective and leads to |
|
| 389 |
+quicker implementation of desired features. |