site.h.in

/*
 * 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.
 */