The "--with-xxx" options: suggestions

[David Lee]

Samba has various "--with-xxx" options, which are extremely useful for
getting new, experimental options out to the user community, whilst
preserving the stability of the core Samba code.  (That is, the average
user can rely on Samba "as-is" to be stable, and the more adventurous user
still has easy, but "opt in", access to the experimental features.) 

But I wonder whether we do enough actively to follow through these options
into full service, and whether we give enough control?

Examples close to my own heart are "--with-quotas" and "--with-utmp", but
this message concerns the general principle, not just those two. 

1. "--with-utmp" seems to have it right (although I egocentrically blow my
   own trumpet and set myself up for a great fall...)

2. "-with-quotas" seems to have a flaw.

===

When I introduced "--with-utmp", I also introduced a boolean smb.conf
parameter "utmp" to switch the feature on or off (per share in this case). 
There are two "opt in" risk aspects during the development months; note
the distinctions ande dependency:

1. "--with-utmp" at build:  An "opt in" build-time risk.

2. "umtp" boolean in smb.conf:  A dependent "opt in" run-time risk.

This principle attempts to be as safe as possible for the end user, and
also to separate out and control the build-time and run-time risks. 

Once the code is basically stable and portable, the build/compile-time
risks are minimal, so we can drop the "--with-xxx"  option (or default it
to "on"), and compile it by default.  But the presence of the boolean
switch in "smb.conf", and its "off" default, still ensures that we
minimise the run-time risks to the average end user.  This "opt in"
availability and control seems to be a good pattern. 

===

The problem in "--with-quotas" is that it lacks the "smb.conf" boolean
flag.  This has both retarded its development to full production use
and restricted its deployment.

1. This has been around for a long time, so we should be able to compile
   it in by default.

2. We add a per-share parameter "quota" (or "df quota"), defaulting to
   "off" (minimal surprise to non-quota sites).  For the relatively few
   sites who use it, it simply means that our explicit opt-in action of
   "--with-quotas" is replaced by opt-in of the "quota" parameter.

===

Summary:

1. Each "--with--xxx" needs a "champion" to push it through to full
   availability (i.e. default to be compiled in).  (And if no champion is
   forthcoming, the Samba Team can threaten to remove the facility!)

2. Each "--with-xxx" should have an appropriate "smb.conf" option,
   defaulting to "off" (or equivalent) for opt-in per-site (or per-share
   or whatever) deployment.

3. Given the above, "package" developers for various platforms (who by
   definition are experienced and likely to be close to samba-technical)
   should be encouraged to include the "--with-xxx" options, as they
   themselves are debugging the code.  Meanwhile the boolean smb.conf
   switch is then available to the end-users: its off-default protects
   most end-users at run-time.

4. In the particular case of "--with-quotas" we need a per-share parameter
   called "quota" (or "df quota" or similar), defaulting to "off", with a
   "README"/"CHANGELOG"/whatever note, indicating the change to the opt-in
   mechanism (from compile-time to per-share run-time).

Thoughts?

-- 

:  David Lee                                I.T. Service          :
:  Systems Programmer                       Computer Centre       :
:                                           University of Durham  :
:  http://www.dur.ac.uk/t.d.lee             South Road            :
:                                           Durham                :
:  Phone: +44 191 374 2882                  U.K.                  :