5 ms·

@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 methodol

@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

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