RFC: New FreeBSD support model

[Michael W. Lucas]

This is very well written. I liked the model at BSDCan, I still like
it.

Speaking as a consumer and doc person: I hope you'll also have a much
briefer document that says "This is how FreeBSD 11+ support works." If
not, well, I'll have to write that blog posting and attach it to a PR. ;-)

On Fri, Jan 23, 2015 at 07:13:17AM -0800, Alfred Perlstein wrote:
> I understand this is like the talk we had at last Bsdcan?  If so this looks like a smart step forward that will both preserve project resources while also providing downstream a guide on how to survive in the new model. In addition this new model appears similar to the model taken by most other commercial vendors. 
> 
> Thank you Gavin, looks good!
> 
> Sent from my iPhone
> 
> > On Jan 23, 2015, at 6:51 AM, Gavin Atkinson <gavin at FreeBSD.org> wrote:
> > 
> > 
> > Hi all,
> > 
> > Over the past year or so, many discussions have been had both internally 
> > and with vendors about the current FreeBSD support model, and how it could 
> > be improved to better suit the (often conflicting) needs of downstream 
> > vendors.
> > 
> > Below is our current draft of the new support model.  I'm sending this to 
> > you as you represent a good cross-section of different downstream users of 
> > FreeBSD.  We're aiming to make these changes soon, and are interested in 
> > knowing what else a consumer of FreeBSD, like your company, might need to 
> > know in order to have a smoother transition.  Michael, I'm including you 
> > for any insight you may wish to offer from your recent efforts in 
> > researching FreeBSD sysadmin-y things.
> > 
> > Thanks,
> > 
> > Gavin
> > 
> > 
> > Changes to the FreeBSD Support Model
> > -----------------------------------------------------------------------
> > 
> > Over the past several months, the teams responsible for supporting the
> > FreeBSD operating system discussed the current support model, and how
> > that model can be improved to provide better support for FreeBSD users
> > and consumers.
> > 
> > The changes below greatly improve FreeBSD support, reduce turnaround time 
> > for Errata Notices and Security Advisories, provide consistency between 
> > binary package sets and the underlying FreeBSD base system version, and 
> > reduce the amount of time before new features are included in the official 
> > FreeBSD binary package sets.
> > 
> > 
> > Changes Proposed in a New FreeBSD Support Model
> > -----------------------------------------------------------------------
> > 
> > The proposed changes include:
> > 
> > - Moving from a point release-based support model to a set of releases
> >  from a branch with a guaranteed support lifetime.
> > 
> > - Resolving our arbitrary (and unofficial) 5-year branch lifetime 
> >  guarantee.  The support policy is that the stable/X branch will be 
> >  supported for 5 years (minimum) from the point X.0-RELEASE is released.  
> >  We now guarantee a 5-year lifetime on the branch, regardless of how many 
> >  releases are built from the branch. Additionally, a "last minute" 
> >  release from the stable/X branch does not constitute expanding the support 
> >  lifetime for the branch as a whole for an additional two years.
> > 
> > - The Security Officer or Ports Management Team may extend support for any 
> >  individual numbered release or branch at their discretion, in 
> >  exceptional cases.
> > 
> > - A new stable/ branch release will not occur before two years after the 
> >  X.0-RELEASE from the prior branch.  This limits the number of 
> >  simultaneous supported branches, which will greatly reduce the overall 
> >  number of branches that must be maintained and build-tested for 
> >  Security Advisories and Errata Notices, reducing turnaround time.
> > 
> > - Each new release from the stable/X branch deprecates the previous 
> >  release on the branch, providing a three-month window within which 
> >  consumers are urged to upgrade to the latest release.  During this 
> >  three-month window, Security Advisories and Errata Notices will still 
> >  be issued for the previous release, as necessary.
> > 
> > 
> > How These Changes Benefit FreeBSD Consumers
> > -----------------------------------------------------------------------
> > 
> > These changes to the FreeBSD support policy will reduce turnaround time  
> > for security advisories and errata notices, provide binary package sets 
> > that are more closely aligned with the latest FreeBSD release from a given 
> > branch, and clearly define the minimum length of time that a branch will 
> > receive support.
> > 
> > 
> > When The New FreeBSD Support Policy Will Become Effective
> > -----------------------------------------------------------------------
> > 
> > These changes are planned to become effective with FreeBSD 11.0-RELEASE,
> > which is still a number of months away.
> > 
> > FreeBSD releases from earlier branches will continue to be supported in 
> > accordance with the policy that was in effect at the time they were 
> > released.
> > 
> > 
> > Deficiencies in the Current FreeBSD Support Model
> > -----------------------------------------------------------------------
> > 
> > - The FreeBSD support model is release-based, versus branch-based. 
> >  Specifically, we determine if a FreeBSD release will be a normal- or an 
> >  extended-support release in the final phases of the release cycle, while 
> >  in reality we have no way to determine how successful the release is 
> >  until weeks or months later.
> > 
> > - We do not clearly define how long the stable/X branch will be supported 
> >  after its creation.  Since FreeBSD 5.x, we have historically supported a 
> >  stable/X branch for a minimum of five years after the X.0-RELEASE is 
> >  available.  The length of time is not a defined policy, which can make 
> >  it difficult to decide which branch to track.
> > 
> > - The current support model prevents building third-party binary packages 
> >  for the most recent release from a stable/ branch because we must 
> >  provide packages that can be run on the oldest supported release from 
> >  the branch.
> > 
> > - Ports maintainers must support the oldest supported release on the 
> >  branch within the Ports Collection. This adds significant complexity to 
> >  the tree in general, but also prevents enabling new features by default.  
> >  An example is the upgrade to WITH_NEW_XORG where these features depend
> >  on changes to the base system that are only available in X.Z-RELEASE.
> > 
> > - The support model can overlap in non-intuitive ways, making it difficult 
> >  to decide when evaluating FreeBSD features versus support timeframe from 
> >  any given branch.  When changes to the support model were initially 
> >  being discussed, the FreeBSD supported releases were:
> >  - 8.4-RELEASE: June 30, 2015
> >  - 9.1-RELEASE: December 31, 2014
> >  - 9.2-RELEASE: September 30, 2014
> > 
> >  (Note that in this case support for the newer 9.2 release ends before 
> >  support for FreeBSD 9.1.)
> > 
> > - A new release from a branch automatically extends the support lifetime 
> >  by two years, minimum.  If X.Y-RELEASE was initially planned to be the 
> >  final release from the stable/X branch, it is an extended-support 
> >  release by definition.  If it is necessary to follow X.Y-RELEASE with 
> >  X.Z-RELEASE for any reason, we would have two concurrent 
> >  extended-support releases from the same branch in sequence. This has a 
> >  serious impact on the quality of an update when there are multiple 
> >  supported releases on a branch. The problem becomes worse when the 
> >  oldest supported release on the branch has a longer support lifetime 
> >  than the newest release on the branch.
> > 
> > 
> > Key Items Considered in Changes to the FreeBSD Support Model
> > -----------------------------------------------------------------------
> > 
> > Some of the things that should be included in a new FreeBSD support
> > model include:
> > 
> > - Guaranteeing, and explicitly stating, the support lifetime of the 
> >  stable/X branch as a whole, versus independently determining the 
> >  support lifetime of the individual releases from the stable/X branch.
> > - Providing package sets that are compatible with the latest release from 
> >  the branch, ensuring that new features introduced into the FreeBSD base 
> >  system can be enabled by default in binary package builds.
> > - Security Advisories and Errata Notices should be more aligned between 
> >  src/ and ports/.  There is an endless list of edge cases with this 
> >  particular point, but consider a situation where a critical security 
> >  vulnerability is discovered, and the underlying code has changed between 
> >  X.Y-RELEASE and X.Z-RELEASE.  In addition to the possibility of 
> >  regression in one (or both) of the supported releases due to subtle 
> >  changes in the security fix, it introduces potential delay in providing 
> >  the security fix as the number of supported releases increases.  Each 
> >  supported release adds to the amount of time it takes for:
> > 
> >  - 1) patching the vulnerability,
> >  - 2) testing the patch,
> >  - 3) verifying the patch is correct, and
> >  - 4) building the freebsd-update(8) binary update bits.
> > 
> >  If a problem is discovered at any time during step (4), procedure resets 
> >  to step (1).  (It should be stressed that this is not due to lack of 
> >  hardware, but the order in which the various steps of issuing Security 
> >  Advisories and Errata Notices must occur.)
> > 
> > - Providing a support model that is easier more predictable and easier to 
> >  follow.
> > 

-- 
Michael W. Lucas  -  mwlucas at michaelwlucas.com, Twitter @mwlauthor 
http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/