From owner-freebsd-hackers  Fri Jul 21 21:48:09 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.11/8.6.6) id VAA09401
          for hackers-outgoing; Fri, 21 Jul 1995 21:48:09 -0700
Received: from lightlink.satcom.net (lightlink.satcom.net [204.33.174.10])
          by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id VAA09393
          ; Fri, 21 Jul 1995 21:48:06 -0700
Received: (from iidpwr@localhost) by lightlink.satcom.net (8.6.12/8.6.9) id VAA11103; Fri, 21 Jul 1995 21:54:27 -0700
Date: Fri, 21 Jul 1995 21:54:27 -0700
From: Imperial Irrigation District <iidpwr@lightlink.satcom.net>
Message-Id: <199507220454.VAA11103@lightlink.satcom.net>
To: iidpwr@lightlink.satcom.net, jkh@time.cdrom.com
Subject: Re: What people are doing with FBSD
Cc: freebsd-hackers@freefall.cdrom.com, hsu@cs.hut.fi,
        jmacd@freefall.cdrom.com, karl@mcs.com, terry@cs.weber.edu
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

What suggestion?  Provide an upgrade path?  Trust me, we're working
on it! :-)

Sorry, I didn't make myself clear.
The suggestions refer to (1) seperate the configuration data
from the executable scripts such as rc, rc.local, netstart, ...etc.
The advantage of seperating the configuration data from the executable scripts
is easier to debug for both the user and the developer.
(2) provide an upgrade path. That would speed up the development too because
the current developer can upgrade to the latest and greatest. Moreover, that
would close the gap between commercial grade OS and non-commercial OS.
Most importantly provide an upgrade path is user friendly. Make the user
happy.