Changes to the FreeBSD Support Model

https://lists.freebsd.org/pipermail/freebsd-announce/2015-February/001624.html

by emaste • 11 years ago

66 40 11 years ago

lists.freebsd.org

tiffanyh2• 11 years ago

@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

[2] https://lists.freebsd.org/pipermail/freebsd-hackers/2012-Jan...

tedunangst• 11 years ago

Not rsync (and not a fan of LTS), but hopping around his major points.

Five year support for a release every two years still means three balls in the air.

No dedicated timeline for minor releases. Could still be 13 months between 11.1 and 11.2.

Doesn't address question of what actually gets back ported. Will new em updates go into stable?

cperciva10• 11 years ago

Five year support for a release every two years still means three balls in the air.

Yes. Although this is probably better characterized as "two balls actively being thrown and one ball on its way down", since we've never done new point releases in the last year of a major branch (and I doubt that will change).

No dedicated timeline for minor releases. Could still be 13 months between 11.1 and 11.2.

Correct. We decided many years ago that FreeBSD worked better if we did releases "when they were ready" rather than working to a calendar. I'm sure OpenBSD's schedule works well for OpenBSD, but our projects are quite different (e.g., OpenBSD development is more centralized in a small number of hands).

Doesn't address question of what actually gets back ported. Will new em updates go into stable?

FreeBSD is a volunteer project. Updates get merged if someone merges them. Aside from policy restrictions, which are not changing (e.g., we won't merge ABI or API-breaking changes, because we insist on supporting third-party software), it's entirely up to people having the time and interest.

rsync3• 11 years ago

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

[2] https://lists.freebsd.org/pipermail/freebsd-hackers/2012-Jan...

[3] bank on it.

cperciva10• 11 years ago

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

emaste2• 11 years ago

Spacing major releases out by five years doesn't guarantee that the bug fixes and driver updates you want will make it into the stable release. It's completely plausible that volunteers will instead develop on HEAD and commit their work there, and the changes won't be merged to the stable branch at all.

I started as a FreeBSD developer in the 4.x era. It was somewhat of an anomaly. The SMP work that went into (and delayed) 5-CURRENT was absolutely necessary, but it introduced significant instability and ongoing breakage. That was a strong disincentive to using it as a day-to-day development platform. I needed a stable development and build machine, so it ran 4.x.

Since then as a project we've done increasingly well at keeping -CURRENT in a working state. It is completely feasible for a volunteer developer to run only -CURRENT.

X-Istence4• 11 years ago

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?

tiffanyh2• 11 years ago

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

cperciva10• 11 years ago

11 will be supported for no less than 5 years

FWIW, this was how long we typically supported releases anyway -- FreeBSD 6.x was supported from November 2005 until November 2010, FreeBSD 7.x was supported from February 2008 until February 2013, FreeBSD 8.x from November 2009 until June 2015, and FreeBSD 9.x from January 2012 until December 2016 -- but we heard from users that a promise was far more useful than a vague "well, typically...".

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)

This is really the most important change, and addresses a problem we've had for a while: When a point release comes out, we have no idea how long it will be until the next point release. For both users and the security team, knowing the end of the support period relative to the arrival of the next point release (i.e., the overlap time) turns out to be more important than knowing the end of the support period relative to the start of the support period.

X-Istence4• 11 years ago

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

vacri• 11 years ago

Phrases like "will not occur before two years after" are not particularly straight-forward. I found some of the prose in this release curly and baroque; if you have to re-read a sentence a few times to get the meaning right, it's not clear language.

cperciva10• 11 years ago

How does this compare to LTS from Canonical/Red Hat?

Ubuntu has a LTS release every 2 years, which is supported for 5 years. FreeBSD will have a release every 2ish years, which is supported for 5 years.

How easy is it going to be to keep up with the changes between the minor releases?

It's already relatively straightforward by using freebsd-update, but work is underway to simplify this further.

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?

None. This is, after all, a volunteer project; if nobody is interested in backporting a driver, it isn't going to get backported. Also, from time to time there are new devices which require significant changes to the underlying kernel architecture (video drivers and virtual memory come to mind, for example), and those are often impossible to merge back because doing so would break internal interfaces used by third-party drivers.

X-Istence4• 11 years ago

I understand that major devices will be impossible or difficult to merge back, especially if there are invasive changes. In the past though even relatively simple changes were not MFC'ed until someone asked for it, and once MFC'ed it took a long time for it to appear in a point -RELEASE. Tracking stable/ isn't for the faint of heart, and especially isn't for those of us that want to do binary upgrades.

Will this change in the support policy allow point -RELEASE's to be made more often, thereby more closely tracking changes on that particular branch of stable? Rather than some of the 8+ months that have happened in the past between point releases?

Thank you for clarifying cperciva!

Scramblejams3• 11 years ago

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.

cperciva10• 11 years ago

Ports is a separate issue. We simply don't have the manpower to maintain old versions of 20000 pieces of third-party software for five years.

Scramblejams3• 11 years ago

Thanks for your response, understood. I'm new to FreeBSD and as a result I didn't find the announcement clear enough to know.

Is there any chance the quarterly approach may get stretched out to cover a longer time period? Anything would be helpful to give busy sysadmins breathing room.

GalacticDomin8r3• 11 years ago

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/

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.

cperciva10• 11 years ago

ports has already had this for some time:

I think he meant branches which are supported for an extended duration. The quarterly branches are (currently, and as far as I know this isn't going to change) supported only for the quarter in question.

Scramblejams3• 11 years ago

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.

api• 11 years ago

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• 11 years ago

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• 11 years ago

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.

GalacticDomin8r3• 11 years ago

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

So you went from downstream to upstream and the view was largely the same. Yeah that's expected.

I think the opening for FreeBSD and everyone else is that with containers and virtualization

FreeBSD has had container based virtualization for 15 years. I know it's the Brittany Spears of the linux dev group ATM, but I doubt it and Docker are as big a thing as it seems now. Container based virtualization is great, but it's not a substitute for a real hypervisor. As more people realize the last fact, the shine will wear off.

microtonal• 11 years ago

I think it has a bit of an opening given the outrageous fragmentation of the Linux ecosystem. There are what... three different inits?

And in BSD the fragmentation is not only in inits, but the whole kernel and base system. We have FreeBSD, NetBSD, OpenBSD, and DragonFly BSD. Then there are sort-of-forks like Darwin and JunOS.

If we divide the number of active developers by the number of variants, I am pretty sure that Linux is doing much better.

There are good reasons for using BSD, but the lack of fragmentation is not one of them.

justincormack• 11 years ago

Linux has enormously more developers than all the BSDs put together. However the BSDs still manage to provide useful platforms that work well for large numbers of use cases, and provide innovation.

kokey• 11 years ago

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?

jarcane• 11 years ago

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.

Changes to the FreeBSD Support Model

Related Stories