[master] 492c9bfb0 Add criteria for bundling new VMODs to the dev-guide.

Geoff Simmons geoff at uplex.de
Mon Feb 25 14:37:08 UTC 2019


commit 492c9bfb0f7e849652161dc88567b3a078aa5db8
Author: Geoff Simmons <geoff at uplex.de>
Date:   Mon Feb 25 15:35:53 2019 +0100

    Add criteria for bundling new VMODs to the dev-guide.
    
    References #2912

diff --git a/doc/sphinx/dev-guide/index.rst b/doc/sphinx/dev-guide/index.rst
index f1c818245..633a0102c 100644
--- a/doc/sphinx/dev-guide/index.rst
+++ b/doc/sphinx/dev-guide/index.rst
@@ -81,3 +81,35 @@ These rules are imported from the X11 project:
 
 * Provide mechanism, rather than policy.
 
+Bundling VMODs with the Varnish distribution
+--------------------------------------------
+
+Decisions about whether to add a new Varnish module (VMOD) to those
+bundled with Varnish are guided by these criteria.
+
+* The VMOD is known to be in widespread use and in high demand for
+  common use cases.
+
+* Or, if the VMOD is relatively new, it provides compelling features
+  that the developer group agrees will be a valuable enhancement for
+  the project.
+
+* The VMOD does not create dependencies on additional external
+  libraries. VMODs that are "glue" for a library come from third
+  parties.
+
+  * We don't want to add new burdens of dependency and compatibility
+    to the project.
+
+  * We don't want to force Varnish deployments to install more than
+    admins explicitly choose to install.
+
+* The VMOD code follows project conventions (passes make distcheck,
+  follows source code style, and so forth).
+
+  * A pull request can demonstrate that this is the case (after any
+    necessary fixups).
+
+* The developer group commits to maintaining the code for the long run
+  (so there will have to be a consensus that we're comfortable with
+  it).


More information about the varnish-commit mailing list