Re: TCP SACK backport to -STABLE

From: Jon Noack (noackjr_at_alumni.rice.edu)
Date: 08/26/04

  • Next message: Paul Saab: "Re: TCP SACK backport to -STABLE" 
    Date: Wed, 25 Aug 2004 17:00:44 -0500 (CDT)
To: "Eli Dart" <dart@nersc.gov>

    Eli Dart wrote:
    > Careful there.....one major reason I use FreeBSD is that, compared
    > with the other operating systems I can use, major breakages are rare.
    >
    > I expect the policy that prevents you from deploying the most
    > featureful OS available is there to avoid the late-night pain
    > required to run the latest and greatest features in production.
    >
    > It would be a shame if stability were lost in a rush for new
    > features. If smarter people than I feel that SACK should be
    > backported, great. However, I for one greatly appreciate the
    > commitments to stability and POLA that are so much a part of FreeBSD.

    >From the Release Engineering document:
    FreeBSD-CURRENT is the "bleeding-edge" of FreeBSD development where all
    new changes first enter the system. FreeBSD-STABLE is the development
    branch from which major releases are made. Changes go into this branch at
    a different pace, and with general assumption that they have first gone
    into FreeBSD-CURRENT and have been thoroughly tested by our user
    community.

    These types of backports happen all the time, and having another person to
    share the load is not a bad thing. Active maintenance of RELENG_4 is good
    for everyone, and those interested most likely have stability as their
    first priority anyway (because otherwise they wouldn't be using RELENG_4).

    Regardless, the original work was done on RELENG_4 and ported to -CURRENT:
    http://lists.freebsd.org/pipermail/cvs-src/2004-June/025956.html

    Jon

    _______________________________________________
    freebsd-net@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"

  • Next message: Paul Saab: "Re: TCP SACK backport to -STABLE"

    Relevant Pages

    • Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
      ... This whole discussion is really interesting as it clearly showcases two common trends in computing (rapid development vs stability) On the one side we got people who are more interested in development than stabilization of the existing code base. ... They really do not care about "new features", but they do care about maximum stability of the existing code, security, and nonstop business continuity even in the face of natural disasters. ... There are definitely points of conflict along these lines, but much of the time the reason that people use FreeBSD is precisely because there *is* agreement on these points. ... If FreeBSD developers only hung around to do adventurous new feature development, we wouldn't have -STABLE branches, errata/security branches, freebsd-update, and so on. ...
      (freebsd-stable)
    • Re: quota deadlock on 6.1-RC1
      ... There are always tradeoffs between stability and features. ... to declaring 5.X "STABLE" until all the major bugs were fixed. ... running freebsd servers around the world will suffer problems because ...
      (freebsd-stable)
    • Re: quota deadlock on 6.1-RC1
      ... FreeBSD already has many great features which we are happy with, but they need to be refined now. ... Yes, new features are important to stay in the game, but they should not arrive at the sacrifice of stability. ... I.e., cleanups of locking models, removal of long-decayed or no longer useful code, finishing up loose ends, etc. Compared to the new feature lists for the 5.x branch, 6.x and 7.x are significantly less agressive. ...
      (freebsd-stable)
    • Re: My disk I/O testing methods for FreeBSD 5.3 ...
      ... Are there any outstanding code changes that will help improve ... > the performance and questions mailing lists under the title " FreeBSD ... > Operating Systems tested: ... > the default installation options as possible with no special tuning. ...
      (freebsd-performance)
    • Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
      ... You talk about feature stability. ... Your view of "stable" meaning "features don't change" is no where near my definition of stable. ... Companies, and users generally, come to FreeBSD not just because they want system stability over time, but also because they expect us to keep producing new features. ... Sure, they may claim otherwise, but in practice they discover they do want FreeBSD to support the latest rev of an ethernet chipset on a motherboard because the replacement parts they received from their hardware vendor have it, support for larger disk sizes, support for a new POSIX API, being able to boot on systems that require ACPI, etc. ...
      (freebsd-stable)