Support for 5.x (Was: Re: What about BIND 9.3.4 in FreeBSD in base system ?)

Chris Marlatt wrote:

Again, why would you expect someone to have already upgraded when they have more than a year of advertised support left on a production release?

I think that there is a misunderstanding here about what "support" means. This discussion has been had in detail on several other lists of late, so let me give you the highlights. There are three main issues.

1. Support for security issues. The secteam has pledged to support the 5.5-RELEASE through 31 May 2008.
2. Ports. The ports team generally pledges to support a release as long as the security team does, but the idea of dropping support early for RELENG_5 has been discussed.
3. New development, performance, features, etc. It is a virtual certainty that none of this will happen in RELENG_5. It is certain (by definition) that no new features will be backported that require ABI breakage, which severely limits what can come back into this branch already.

I personally have very few 5.x systems left, primarily because I've been trying to heed the warnings, but seeing how 5 series is being fast tracked into retirement makes me extremely suspicious of what is to happen to 6 series when 7 is released and considered production.

I can't make any iron clad assurances here, but I can say that this is unlikely to happen, because of why a lot of us want to drop support for 5.x. Namely that it has a lot of issues that cannot be fixed without breaking the ABI. In many key areas, 6.x is light years ahead, and is going to stay that way. There are some incremental improvements in 7-current right now that will make it attractive to some users, but if you're looking for something to install and keep supported for a longer time period, 6.x is going to be it.

I'm sure many other people wonder the same thing and look at the lengthy support for 4 series which lasted 7,... 8 years and have come to expect something similar for future releases.

Which is why we're working so hard to disabuse people of that notion.

Whereas I'm certainly not going to say progress is evil I will admit that the FreeBSD I see today is not the same one from yesteryear.

Nor will it be the same tomorrow. Such is life in a volunteer project.

Now, I can clearly understand and appreciate the burden that, as of yesterday, 3 active versions

Actually it was 4 active versions, including 7-current.

can impose on the development team but why pass part of that burden onto a user base that's done nothing but embraced the products produced by its efforts?

This is where that whole "volunteer project" thing comes in again. With a finite set of resources, we have to be realistic in terms of how thin we can spread them. Right now the rough order of priority is 6-stable, 7-current, 5-stable. It is of course up to you to decide how to manage your own resources, but please don't expect magical things to happen in 5-stable just because you'd like them to. :)



This .signature sanitized for your protection

freebsd-security@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-security-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Other JSF options
    ... the aircraft," says the statement. ... protects sensitive technologies in the JSF, ... production and in-service support of the F-35, ... spares or other support if we ...
  • Re: Moving on ...
    ... For instance, we might have waited an extra 3-5 years for any ZFS support at all in a -RELEASE, and when it appeared, it would introduce a big upgrade hurdle, as it would be accompanied by major underlying changes in system architecture. ... That sounds fair to increase the lifecycle to 5 years, but I think hardware support needs to be available much sooner; perhaps included in the minor releases. ... Instead of having a legacy branch and two production branches, you would have legacy production and ... ...
  • Re: Modern Gunships
    ... > Helos are not as easy to detect and enage as many think they would be, ... >>> Well, if DDX gets its currently planned two AGS systems in each hull, I'd ... While I do not support the ... it's cost spiral and production ...
  • Re: Running REXX program in a batch job
    ... Applications development to write code for production batch, but batch REXX, including batch REXX that runs in batch TSO or batch ISPF environments, has been frequently used by Technical Services to quickly implement a number of simple utilities needed by Applications Development. ... One thing which may make this practical in our environment which I gather may not be true in yours - our production support people are the same people who do application development. ...
  • Re: "Earning" Ones Wage
    ... labor or capital might depend on the particular case, ... capital do make contributions to production, ... at a reasonably high standard of living is not a real possibility ... are support instrumental ends or only reinforce ceremonial ...