7 ms·

Changes to the FreeBSD Support Model

66 points by emaste 12y ago

tiffanyh 12y 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 https://news.ycombinator.com/item?id=8548057 [2] https://lists.freebsd.org/pipermail/freebsd-hackers/2012-January/037294.html https://lists.freebsd.org/pipermail/freebsd-hackers/2012-Jan...
- tedunangst 12y 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?
  - cperciva 12y 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.
    - stock_toaster 12y ago
      Five years seems like a long time to support an OS release, especially for a volunteer project. Do you know if there was any consideration/discussion around a shorter lifecycle (like 3 or 4 years)?
      - cperciva 12y ago
        Yes, there have been people who want to reduce the support timeline. There are also people (mostly vendors who build products on FreeBSD, but also companies which run lots of FreeBSD servers) who wanted a longer support timeline. Like most things, five years was a compromise. :-)
        stock_toaster 12y ago
        I am sure I can only imagine. :) Thanks for the info!
- rsync 12y 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-January/037436.html https://lists.freebsd.org/pipermail/freebsd-hackers/2012-Jan... [2] https://lists.freebsd.org/pipermail/freebsd-hackers/2012-January/037369.html https://lists.freebsd.org/pipermail/freebsd-hackers/2012-Jan... [3] bank on it.
  - cperciva 12y 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".
    - rsync 12y ago
X-Istence 12y 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?
- tiffanyh 12y 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
  - cperciva 12y 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.
Scramblejams 12y 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.
- cperciva 12y 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.
  - Scramblejams 12y 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.
    - cperciva 12y ago
      Is there any chance the quarterly approach may get stretched out to cover a longer time period? To be honest, I don't pay enough attention to the ports side of things to answer this.
- GalacticDomin8r 12y 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/ 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.
api 12y 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 12y 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 12y 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.
  - GalacticDomin8r 12y 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.
kokey 12y 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 12y 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.

66 points by emaste 12y 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 https://news.ycombinator.com/item?id=8548057 [2] https://lists.freebsd.org/pipermail/freebsd-hackers/2012-January/037294.html https://lists.freebsd.org/pipermail/freebsd-hackers/2012-Jan...

tedunangst 12y 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?
- cperciva 12y 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.
  - stock_toaster 12y ago
    Five years seems like a long time to support an OS release, especially for a volunteer project. Do you know if there was any consideration/discussion around a shorter lifecycle (like 3 or 4 years)?
    - cperciva 12y ago
      Yes, there have been people who want to reduce the support timeline. There are also people (mostly vendors who build products on FreeBSD, but also companies which run lots of FreeBSD servers) who wanted a longer support timeline. Like most things, five years was a compromise. :-)
      - stock_toaster 12y ago
        I am sure I can only imagine. :) Thanks for the info!
rsync 12y 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-January/037436.html https://lists.freebsd.org/pipermail/freebsd-hackers/2012-Jan... [2] https://lists.freebsd.org/pipermail/freebsd-hackers/2012-January/037369.html https://lists.freebsd.org/pipermail/freebsd-hackers/2012-Jan... [3] bank on it.
- cperciva 12y 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".
  - rsync 12y ago

X-Istence 12y 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?

tiffanyh 12y 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
- cperciva 12y 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.

Scramblejams 12y 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.

cperciva 12y 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.
- Scramblejams 12y 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.
  - cperciva 12y ago
    Is there any chance the quarterly approach may get stretched out to cover a longer time period? To be honest, I don't pay enough attention to the ports side of things to answer this.
GalacticDomin8r 12y 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/ 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.

api 12y 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 12y 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 12y 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.
- GalacticDomin8r 12y 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.

kokey 12y 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 12y 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.