1 files changed, 44 insertions, 0 deletions
diff --git a/site.h.in b/site.h.in
new file mode 100644
index 00000000000..eb2f062e60c
--- /dev/null
+++ b/site.h.in
@@ -0,0 +1,44 @@
+/*
+ * Guidelines for using this file vs. configure.ac
+ *
+ * (1) If it already exists in configure.ac, leave it there.
+ *
+ * (2) If it needs to take effect at configure (not compile) time, it *needs*
+ * to go in configure.ac.
+ *
+ * (3) If it affects file paths, which are the things most likely to be based
+ * on an OS or distribution's generic filesystem hierarchy and not on a
+ * particular package's definition (e.g. an RPM specfile), it should probably
+ * go in configure.ac.
+ *
+ * (4) If it affects default sizes, limits, thresholds, or modes of operation
+ * (e.g. IPv4 vs. IPv6), it should probably go here.
+ *
+ * (5) For anything else, is it more like the things in 3 or the things in 4?
+ * Which approach is more convenient for the people who are likely to use the
+ * new option(s)?  Make your best guesses, confirm with others, and go with
+ * what works.
+ */
+
+#define SITE_H_ENABLE_LEAST_PRIORITY    "on"
+#define SITE_H_MD_CACHE_TIMEOUT         "1"
+#define SITE_H_NFS_DISABLE              "on"
+
+/*
+ * As an example of how to use this file, here's what the Facebook version looks
+ * like:
+
+#define SITE_H_ENABLE_LEAST_PRIORITY    "off"
+#define SITE_H_MD_CACHE_TIMEOUT         "180"
+#define SITE_H_NFS_DISABLE              "off"
+
+ * Each time we add a value here, we lessen the risk of values being
+ * inconsistent across production automation, test automation, and manual
+ * developer testing. We also save effort compared to updating values for each
+ * kind of external automation. To do the same thing with configure scripts or
+ * specfiles, we'd have to make much more complicated and less discoverable
+ * changes there.
+ *
+ * Other orgs are likely to have the same issues regarding their preferred
+ * settings, and likewise should add their favorites here as well.
+ */