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]
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.
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)?
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. :-)
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.
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".
"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.
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.
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.
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.
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...