Schedule for releases

[Mike Karels]

I'm replying to the thread as a whole rather than a specific message.

I work for a security appliance vendor that may represent the worst case
when it comes to supporting older FreeBSD releases.  I spend a fair
amount of time back-porting device drivers and other hardware support
so we can run the older releases (back to 6.3) on new hardware.  In
fact, we haven't shipped a release based on 6.3 for two years, but
we're still patching it to run on new hardware.

Why so old, a FreeBSD developer asked recently?  There are a number
of factors, which are additive:

- We have significant modifications to the system that have to be merged
and retested in an OS upgrade.  Of course, there is additional testing
for an OS upgrade itself.

- We try to do OS upgrades early in our release cycle, so our own software
development will be done on the delivery platform.

- We generally consider OS upgrades only for a major release of our own,
usually a .0.  These come less often than FreeBSD .0 releases.

- We go through government certifications for some of our releases, but
by no means all.  These certifications take a long time.  Many of our
customers have to run the certified versions.  We can sneak in new
device drivers as a patch, but not an OS upgrade.

- Security customers tend not to run our .0 releases, and often prefer
not to upgrade to a major release for some time, e.g. a major network
upgrade.  For management and policy reasons, they want to keep their
appliances at the same version, and upgrade to a major release is a
lot of work.  Even our internal customers aren't running a recent
release.

A few comments based on the above:

- We realize that we're running an older release, and don't expect
most of the improvements to be MFC'd.  We know that we'll have to
do some of the work to back-port drivers, etc, including testing.
That said, it is helpful when the developers anticipate back-ports,
e.g. leaving ifdefs in place for older versions of bus interface
calls, vlan tags, etc.

- We sometimes back-port other changes, such as TCP locking fixes
that help performance.  Considering some such things for MFC would
be desirable.

- Those of us doing backports could probably do a better job of
sharing the results.  On the other hand, I'm generally backporting
to a specific release (currently 6.3 or 7.2) rather than -stable,
and we're testing our software rather than FreeBSD.

- Less frequent FreeBSD .0 releases would probabaly help us.

- Changing the naming conventions might matter to some users, but
wouldn't affect us much.  I'm currently pushing for a 7.2 to 8.1
or 8.2 upgrade as part of a dot release, and the naming doesn't
really matter to us.

		Mike