[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