
Changes to the FreeBSD Support Model - emaste
https://lists.freebsd.org/pipermail/freebsd-announce/2015-February/001624.html
======
X-Istence
I've been following FreeBSD development for a long time, and I've been
wondering if changes to the support model would be forthcoming and would help
simplify things so that if I build on top of FreeBSD I can be guaranteed some
sort of stability in the longer term.

This announcement while welcome doesn't give me a really good idea of what is
going to change. It would be absolutely fantastic if some examples could have
been included instead of just stable/X.

For example, using hypothetical released named X.0-RELEASE and Y.0-RELEASE and
Z.0-RELEASE what are the branch names going to be called, how often are they
going to be created, and how long are they going to be supported?

How does this compare to LTS from Canonical/Red Hat? How easy is it going to
be to keep up with the changes between the minor releases? What guarantees
does the community have that driver modifications/fixes are not going to get
stuck in -CURRENT or the next major release only, or have to be manually back-
ported?

~~~
tiffanyh
X-Istence, the announcement is very straight forward ... but for the lazy it's
essentially:

Starting with 11, the following will happen:

* All major releases (e.g. 11) will be supported for no less than 5 years

* The N+1 major release (e.g. 12) won't happen any earlier than 2 years after the previous major release (e.g. 11) is released.

* Whenever a new point release is made (e.g. 11.1) all previous point releases will be deprecated after 3 months (e.g. 11.0)

* All stated support timeliness for pre-11 releases will continue as stated before

~~~
X-Istence
Please don't call me lazy. I tried to understand the announcement and it just
didn't make a whole lot of sense so I asked questions about it.

@cperciva answered those questions for me in a much more pleasant way than you
did.

That being said, the reason I am confused is because it doesn't really change
anything. Releases were already for the most part supported for 5 years, and
new releases were already cut once every two years (look at 9.0-RELEASE and
10.0-RELEASE).

~~~
cperciva
_it doesn 't really change anything_

The timeline for dropping support of point releases is important. The rest is
mainly about improving communication: Many users were not aware that we
supported releases for 5 years, for example, because all they ever saw was the
advertised "12 months" or "24 months" for point releases.

~~~
X-Istence
Yes, the understanding for how long point releases will be supported makes a
lot of sense and will definitely help. The rest (5 year support timeline) was
already something I understood from having followed the project for some time,
I just didn't understand if this announcement changed my understanding
thereof.

------
tiffanyh
@rsync

I'd really like to hear your thoughts with regards to this announcement, given
how you've been vocal in your frustration of the FreeBSD support methodology
[1][2]

[1]
[https://news.ycombinator.com/item?id=8548057](https://news.ycombinator.com/item?id=8548057)

[2] [https://lists.freebsd.org/pipermail/freebsd-
hackers/2012-Jan...](https://lists.freebsd.org/pipermail/freebsd-
hackers/2012-January/037294.html)

~~~
rsync
In a followup post to my original January 2012 rant, I suggested the
following[1][2]:

\- A major release every 5 years

\- A minor release every 4-6 months

\- total focus on the major release for essentially that entire 5 year period

Obviously there are more details than that, but the point is, it's not the
five year number that matters - it's the number of branches floating around
simultaneously that is the real problem.

"Instead of having a legacy branch and two production branches, you would have
legacy (8) production (9) and ... nothing. Or if you need to have it out
there, 10 is the development branch. Minor releases come out 2-3 times per
year, which gets you to 9.10 or 9.15 at the end of the cycle."

So ... in looking at this new announcement, it seems like they are addressing
some points that I have brought up in the past, but in reality I think they
are addressing completely different issues, especially with regard to applying
security errata, etc.

The problem I see is the (short) two year embargo on a new release, which
means that over the five year lifecycle of a release, potentially _two_ other
releases come out, which is basically what we have now. Bug fixes and driver
updates get written and applied to the sexy new tree[3], and the "supported"
release that's all of two years old gets none of it.

That's great that it's around for five years, and I appreciate the clarity
there - but there is more to support than the ports tree and security errata.
True support is the developer community working _in and with_ a release for
years, and that hasn't happened since 4.x.

[1] [https://lists.freebsd.org/pipermail/freebsd-
hackers/2012-Jan...](https://lists.freebsd.org/pipermail/freebsd-
hackers/2012-January/037436.html)

[2] [https://lists.freebsd.org/pipermail/freebsd-
hackers/2012-Jan...](https://lists.freebsd.org/pipermail/freebsd-
hackers/2012-January/037369.html)

[3] bank on it.

~~~
cperciva
_The problem I see is the (short) two year embargo on a new release_

If support for a new device can't be merged into older releases because it
relies on ABI/API breaking changes, do you want to be told that you won't be
able to use your shiny new hardware in a FreeBSD release for the next five
years?

Two years is a compromise between "don't try to support too much at once" and
"make sure that people don't have to wait too long to access new features".

~~~
rsync
"If support for a new device can't be merged into older releases because it
relies on ABI/API breaking changes, do you want to be told that you won't be
able to use your shiny new hardware in a FreeBSD release for the next five
years?"

Yes.

As a business user of FreeBSD, with shareholders and a board of directors,
etc., we make very conservative hardware decisions and we try to amortize our
investments over as long a period as is practically possible.

I've never thought this argument was that convincing, especially given the
propensity to see FreeBSD as a server OS. The fancy things are never ready in
the first release they go into _anyway_ , so it's not like we gain much, from
a practical standpoint.

~~~
tw04
Then maintain your own branch like other business users who want to have a
stable branch for extended periods of time. And back port the drivers
internally if you need them back ported. Literally nobody is preventing you
from doing so. There are, however, people that donate extremely large sums of
money to the FreeBSD foundation who do support their current release cycles.

~~~
rsync
First, my suggestions above were made originally in January of 2012, at which
time I committed $50,000 to the FreeBSD project in return for adopting
something like those suggestions.

So your "put your money where your mouth is" trump card was not quite what you
thought it was. Thanks for playing.

Second, I reject the notion that nobody but core developers and big business
has useful viewpoints as to the direction of the FreeBSD project (or any
project, for that matter). You _think_ you know what kind of resources you are
talking about, above, when you speak of developing and maintaining a custom
branch and backporting drivers, etc. Take that number and triple it and that's
a _starting point_ for the true amount of cost something like that would take
in a real organization with real HR and QA and benefits and shareholders and a
functioning board, etc. ...

... and that's out of the realm of even mid sized shops.

------
jarcane
I was quite delighted to hear that this new model will apparently improve
their ability to provide up-to-date package builds and ports.

The main reason I switched over from Linux to BSD was being tired of dealing
with deciding between a bleeding-edge roll-your-own distro that breaks all the
time, or a decrepit one loaded down with packages that've been out of date for
4 or 5 years.

------
api
I've been seeing a lot of new activity around FreeBSD and it's great... I
think it has a bit of an opening given the outrageous fragmentation of the
Linux ecosystem. There are what... three different inits?

~~~
logn
Is it really that fragmented? There's essentially RedHat, Debian, and
Slackware. At the level of app development for servers, everything seems
pretty compatible.

As a desktop user I just switched from Xubuntu to Debian+Xfce and it's nearly
identical.

I'm sure that people who work at the OS level see a lot of fragmentation and
headaches, but to their credit it's largely hidden from the masses.

I think the opening for FreeBSD and everyone else is that with containers and
virtualization, the movement is towards picking an OS per app, not an OS to
run your entire business on.

~~~
ivoras
And SUSE enterprise is another actually popular version, at least what I've
seen in the telecom industry. So that's at least 4.

Then, there's Arch which is popular with enthusiasts, and Ubuntu has become
sufficiently different from Debian that it requires thinking when switching
from one to the other. Gentoo seems to be getting less and less popular, but
it's still kicking.

And yes as the parent post said, it's the unexpected differences that are
stressful: different init systems, selinux vs apparmour vs nothing, different
locations of config files, different whole /etc structures, that sort of
things. The distros are diverging fast, and switching from RHEL to Ubuntu
nowadays feels like it's a whole new system.

------
kokey
What I would like to understand is, will features/versions of packages (not
ports) be frozen between point releases and security and stability fixes be
backported?

------
Scramblejams
Does this mean that version numbers for software in ports and pkg will be
frozen and security fixes backported? That sounds like the relatively new
quarterly model but with support lasting for 5 years instead of phasing out
after 3 months. Given the sentiment elsewhere on this page that "this doesn't
really change anything outside of providing guarantees," my guess is the
answer is no.

Sure would be nice. Coming from Debian, I long for a similar model in FreeBSD.

~~~
GalacticDomin8r
> Does this mean that version numbers for software in ports and pkg will be
> frozen and security fixes backported?

ports has already had this for some time:

[http://svnweb.freebsd.org/ports/branches/](http://svnweb.freebsd.org/ports/branches/)

There might be semi-official repos for those somewhere as well. Or you can
always build your own with poudriere.

> Coming from Debian, I long for a similar model in FreeBSD.

Oh hell no. This gives silly issues like Lenny's pigz being broken for like 4
years. Or OpenSuse's crappy model which shipped a shitty version of kde4 long
after it had become stable elsewhere.

~~~
Scramblejams
If you ship software for Debian and you've been frustrated that your users get
stuck with a lousy version of a dependency, I can understand that.

I've been admining Debian boxes for more than a decade so I'm aware of the
drawbacks of its policies. That's why my desktop tracks unstable. But for a
sysadmin, freezing everything for long periods of time makes for an enormous
reduction in churn-related administration time. Having nothing but security
updates to install until the next version comes out 2+ years later is
excellent. For the exceptions, pinning can often solve the problem. And if
pinning doesn't work, there's always building from source.

Like I said above, I'm new to FreeBSD so I'm not sure how much churn I'll have
to endure, but I'm looking forward to finding out.

~~~
GalacticDomin8r
I understood why you like tracking a security branch as I have been admining
*nix boxes for 15+ years.

Where that approach fails is that as a sysadmin one of the responsibilities is
to provide good tools to the user, not reduce work for the sysadmin. The user
might be a SaaS platform, developers or more traditional (l)users. Regardless,
you want your platform to be stable and efficient from a user perspective.
Tracking a "Security" branch only give you one of those in many cases.

It's an apples to oranges in some regards because FreeBSD OS patchsets are
essentially the "Security" branch while ports is a different issue(and one the
user is most likely concerned about).

