RFC: New FreeBSD support model

[Alfred Perlstein]

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