Re: Upcoming Releases Schedule... - FreeBSD

This is a discussion on Re: Upcoming Releases Schedule... - FreeBSD ; On Sep 19, 2008, at 9:41 PM, Gary Palmer wrote: > On Fri, Sep 19, 2008 at 07:38:32PM -0700, Jo Rhett wrote: >> Without input from the current release team extending the support >> schedule is not possible. > > ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 31 of 31

Thread: Re: Upcoming Releases Schedule...

  1. Re: Upcoming Releases Schedule...

    On Sep 19, 2008, at 9:41 PM, Gary Palmer wrote:
    > On Fri, Sep 19, 2008 at 07:38:32PM -0700, Jo Rhett wrote:
    >> Without input from the current release team extending the support
    >> schedule is not possible.

    >
    > Inquiry - is release team the constraint?


    I don't know. I asked why not, and was told the release team said
    this was all they could do with the resources they have. No further
    information has been provided.

    > Or to put it another way, what to you is "support" in terms of
    > FreeBSD releases. As far as I am aware, if you stick on a
    > RELENG_X_Y_Z_RELEASE tag
    > then the most you get is security fixes. No new features,
    > no new drivers, no bugfixes. So if I am interpreting things
    > correctly, you are asking for security fixes to be ported to
    > RELEASE tagged branches for longer?


    That is what I and my $EMPLOYER want yes, although as I said I am
    willing to support other efforts. (ie I am unlikely to be the
    difference between make or break on this effort, so if more support
    was something that got other businesses involved enough to achieve
    that change, then....)

    > So is release team the contrained resource in your problem?
    > I am not denying that *any* part of the FreeBSD team is not
    > resource constrained, but I'm wondering if you're examining
    > the correct area.


    That's a good question I don't have the answer to. Nobody has
    actually defined the problem to me beyond the statement above. This
    is why it's difficult to determine how to best proceed. Until the
    real problems are laid on the table (so to speak) I haven't the
    foggiest idea where/how/when to help, nor whether or not my or anyone
    else's assistance would be useful. (one assumes it would)
    --
    Jo Rhett
    Net Consonance : consonant endings by net philanthropy, open source
    and other randomness


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


  2. Re: Upcoming Releases Schedule...

    On 2008.09.19 21:30:11 -0700, Jo Rhett wrote:
    > On Sep 19, 2008, at 8:57 PM, David N wrote:
    > > How long are you expecting support for a RELENG to last, 1, 2, 3
    > > years? 5 years? (comparison, Ubuntu LTS is 3 years, security updates)

    >
    > 2 years for each supported branch would be excellent, although I'm
    > open to alternatives. Right now 6.4 will EoL before 6.3 will :-(


    Eh, where did you get that information? AFAIK the EoL date of 6.4 has
    not yet been decided (and I should know though of course I could have
    missed it). The EoL date is normally decided right around the release
    time. In the past it was done post-release but lately it has been
    done before the release to include info in the release announcement.

    If, when we get closer to the actual release, still is the plan for
    6.4 to be the last RELENG_6 release I'm almost certain 6.4 will be a
    Extended Support release.

    On 2008.09.19 22:43:56 -0700, Jo Rhett wrote:
    > On Sep 19, 2008, at 9:41 PM, Gary Palmer wrote:
    > > On Fri, Sep 19, 2008 at 07:38:32PM -0700, Jo Rhett wrote:
    > >> Without input from the current release team extending the support
    > >> schedule is not possible.

    > >
    > > Inquiry - is release team the constraint?

    >
    > I don't know. I asked why not, and was told the release team said
    > this was all they could do with the resources they have. No further
    > information has been provided.


    Initially, the description is from my "world view". It's entirely
    possible I miss some parts, have forgotten, or remember incorrectly.



    OK, before being able to say what is required for support, we need to
    define "support".

    Currently the entities which has a defined support for releases is the
    FreeBSD Security Team (secteam) which supports the base system for
    RELENG_* as defined out the security website [1], and the FreeBSD
    Ports Management Team which has defined "support" for the FreeBSD
    Ports Collection.

    The security team will, for the defined periods, do it's utmost to
    make sure security issues identifies in the supported branches are
    fixed. When it has been published how long a release is supported,
    that period may at times be extended, but it's never shortened. It
    should be mentioned in this regard that after a release is out the
    door and hasn't blown up requiring a point release to fix it (think
    4.6.2 / 5.2.1) the security team owns the release branch, so to speak.

    The Ports Collection has a slightly more vague definition of what is
    "supported" [2], but it is still documented. Ports normally "support"
    the releases secteam does, but they could support less if they want
    to. For the Ports Collection there is also two parts to that
    "support" (and that's the reason I write "support" with quotes). One
    part is the ports infrastructure (bsd.ports.mk and more) which portmgr
    and others do a lot to make sure works on the supported releasess.
    The other part is the ~19000 individual ports. The individual ports,
    to a degree, supports what the maintainer of that port has an interest
    in supporting. While there are of course rules and guidelines for
    what a port must support, if a maintainer doesn't want to spend time
    supporting it there aren't that much anyone else can do about it (if
    somebody else cares enough they can submit patches, but e.g. for X000
    broken ports that's a lot of work).

    The Release Engineering team implicitly (as in that I don't think they
    ever defined this per policy but it's what effectively being done)
    support whatever secteam supports, wrt. for Errata Notices. As the
    security team "own" the release branches (RELENG_X_Y) secteam is also
    involved at least partly in each Errata Notice which goes out.

    Now, to define what the above support requires.

    For the ports collection (if we ignore the part with individual ports
    maintainers) requires quite a lot of time per release to support
    (especially for older releases), as all infrastructure changes has to
    be tested on all supported versions, and for each supported release
    and architecture there need to be hardware to build packages. I'm not
    going to go more into this as I'm not involved with this so I don't
    know the details on than that it's non-trivial both wrt. time and
    hardware.

    For what secteam support of the base system costs, it's mainly time
    for the members of the security team which is the cost. The more
    branches, the more time is required. This is not a linear cost and
    has multiple parts to it:

    - The more branches are supported, the more likely it is we need to
    deal with a security issue for third party software. Both because
    software is added/removed in newer branches so we might only support
    a given program in old branches (e.g. GNU tar, GNU gzip, GNU cpio
    and more hare not in newer FreeBSD versions). It's also possible
    that an older release will have a vulnerable version, but newer
    FreeBSD versions are not vulnerable due to newer version of the
    third party software.

    It also happens that an FreeBSD specific issue has silently /
    unknowingly to the security impact been fixed in newer FreeBSD
    versions, but that is very rare.

    - The more branches are supported, the more versions of both third
    party code and FreeBSD code need to be supported and the more likely
    it is that the software differs meaning that we need to adopt the
    fix to the branch. The real painful case for this was
    FreeBSD-SA-07:01.jail which AFAIR needed 6 different patches. This
    is one of the largest time cost with support many branches as this
    is by no means a linear cost. The older a branch is, the more
    likely it is that the code is much different than newer FreeBSD
    versions.

    This also the reason secteam was very happy when we could
    discontinue FreeBSD 4 support as it was significantly different from
    FreeBSD 5+. In that respect supporting FreeBSD 5 in the end was
    much cheaper than supporting FreeBSD 4 in the end. Of course this
    is less likely to be a problem in the future like it was with
    FreeBSD 4, but still - FreeBSD 5 and FreeBSD 8 are rather different
    and would not be fun to support both.

    - Even if we don't need different patches for older releases we still
    need to look at them for each advisory and potentially do separate
    testing for each release.

    - For some issues which are e.g. in the platform (as in i386, amd64,
    sparc64 etc.) dependent FreeBSD code or otherwise platform dependent
    code the complexity and time is a multiple of numbers of supported
    platforms and supported branches. There aren't many issues of this
    type but they could happen.

    - The actual advisory handling takes longer time the more releases is
    involved as the advisory need to contain info per release and
    patches need to be applied per branch both to the subversion tree
    and freebsd-update. This is not a big part, but it still takes time
    when you have 8 supported branches like we did at one point.

    There is also a cost in hardware for supported branches though this is
    less of an issue. Hardware is needed for testing / developing patches
    and for freebsd-update builds. Since we now have VMware and qemu
    hardware for reference systems are a smaller problem now. The time
    freebsd-update builds takes is an issue, but not a big one as we could
    "just" get more hardware if needed.

    The more releases are supported, the more disk-space is also needed
    for freebsd-update mirrors. Again, far from an unsolvable problem by
    any means, but also a factor - included for (slightly more)
    completeness.

    This is the "costs" I could come up with now - I'm sure there are more
    which I have forgotten.

    While I'm not going more into the general discussion of how long to
    support branches, I will note that as rwatson has said - adding more
    people to secteam is not as simple as it sounds (though we are in the
    process of expanding right now).

    Other is the thread have mentioned external people could support the
    older branches. This is partially correct, but only if the support is
    distributed externally as well. Even after a branch is not supported
    anymore the FreeBSD Security Team holds a lock on the branch and only
    in special cases allow commits to those branches. The reason for this
    is that some people might still just pull the latest version for
    RELENG_X_Y for whatever reason and they should not "suddenly" get less
    verified code. Newer patches also wouldn't make it to freebsd-update
    as that is managed by secteam.

    We have had one case where a committer was interested in supporting an
    older release and back-ported patches from security advisories for a
    while. The patches for the older releases were then reviewed in each
    case by the security team before commit, but that only lasted for a
    while and was a couple of years ago AFAIR. In theory this could
    happen again if the Security Officer at the time is OK with it - I
    haven't talked with Colin about this in a while, so I can't recall is
    position. There would still need to be committer which is the
    interface to secteam and do the commits. Most issues (though of
    course not all) which gets advisories are not public at the time of
    the advisory, so a fix to older branches would be likely be delayed
    some compared to initial disclosure.

    I hope this makes it a bit clearer what the cost of supporting old
    releases is (and even then I haven't gone much into the important part
    of also having ports support).

    [1] http://security.FreeBSD.org/
    [2] http://www.freebsd.org/ports/

    PS. I hope there aren't too many spelling and grammar errors in this
    mail, but just reading it over one time was more than enough :-).

    --
    Simon L. Nielsen
    Hat: FreeBSD Deputy Security Officer
    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  3. Re: Upcoming Releases Schedule...


    On Sat, 20 Sep 2008, netgeek wrote:

    >> Don't get me wrong: I would love to see us support all releases for 24
    >> months (or even more) after they ship. I think our users would appreciate
    >> that also.

    >
    > Perhaps there is a middle ground here? What about a statement that each
    > major branch (6.x, 7.x) will be supported for at least 24+ months from its
    > last production release? Smaller periods of support could be given to minor
    > releases along the way (7.2, for example), but at least companies would know
    > that if they installed a 6.x version, they'd have support for a couple of
    > years, even if that might mean upgrading to a newer minor version if there
    > was a problem.


    This is precisely what we already do -- we guarantee we will support the last
    release on a branch for 24 months after the release. The point of concern
    being discussed is that we can't tell you for sure which minor release will be
    the last release at the time that release goes out the door, because the
    extent to which we keep releasing on old branches depends in large part on how
    the new branch looks.

    Right now, it sounds like 6.4 will be the last minor release on the 6.x
    branch, but I think it would be a mistake to commit to that decision until 7.1
    has settled in for a few months and we believe firmly there is a good
    migration path forwards to the 7.x branch. 7.0 was arguably one of the most
    stable .0 releases we've ever done (perhaps the most stable -- 4.0 was pretty
    good though), so it seem almost certain 7.1 will be really stable, but stable
    is what happens when people install it and it works well in practice, so
    there's always a wait-and-see element.

    Robert N M Watson
    Computer Laboratory
    University of Cambridge
    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  4. Re: Upcoming Releases Schedule...


    On Sat, 20 Sep 2008, Simon L. Nielsen wrote:

    > - The more branches are supported, the more versions of both third
    > party code and FreeBSD code need to be supported and the more likely
    > it is that the software differs meaning that we need to adopt the
    > fix to the branch. The real painful case for this was
    > FreeBSD-SA-07:01.jail which AFAIR needed 6 different patches. This
    > is one of the largest time cost with support many branches as this
    > is by no means a linear cost. The older a branch is, the more
    > likely it is that the code is much different than newer FreeBSD
    > versions.
    >
    > This also the reason secteam was very happy when we could
    > discontinue FreeBSD 4 support as it was significantly different from
    > FreeBSD 5+. In that respect supporting FreeBSD 5 in the end was
    > much cheaper than supporting FreeBSD 4 in the end. Of course this
    > is less likely to be a problem in the future like it was with
    > FreeBSD 4, but still - FreeBSD 5 and FreeBSD 8 are rather different
    > and would not be fun to support both.


    Let me give an example from a slightly older branch here as well: we
    de-supported FreeBSD 3.x for "local" security vulnerabilities because we hit
    the libncurses security vulnerability. The only real option to pick up the
    fix was to adopt new version of libncurses, and that radically changed the
    libcurses API (part of the fix). This, in turn, cascaded into other
    applications, such as top, vi, etc, which all use ncurses, so the net effect
    would have been not just a significant API change, but also modifications to
    countless system utilities. Such a change might not even be appropriate for a
    minor branch, let alone a security branch where we try to ensure minimalist
    fixes to avoid security patches leading to other potential regressions.

    Robert N M Watson
    Computer Laboratory
    University of Cambridge
    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  5. Re: Upcoming Releases Schedule...

    On Sat, Sep 20, 2008 at 9:52 PM, Aristedes Maniatis wrote:
    >
    > On 21/09/2008, at 10:34 AM, netgeek wrote:
    >
    >> Perhaps there is a middle ground here? What about a statement that each
    >> major branch (6.x, 7.x) will be supported for at least 24+ months from its
    >> last production release? Smaller periods of support could be given to minor
    >> releases along the way (7.2, for example), but at least companies would know
    >> that if they installed a 6.x version, they'd have support for a couple of
    >> years, even if that might mean upgrading to a newer minor version if there
    >> was a problem.

    >
    > This is already the case [1]. From each major branch one or more releases
    > are designated as 'extended' and supported for 24 months. All you have to do
    > is pick one of those and you've got support for 24 months. For example 6.3
    > has extended support in this way.
    >
    > RELENG_6 itself will be supported 24 months after the last release. Given
    > roughly 18 months between major releases and about 12 months of ongoing
    > releases from the previous branch after that, 4.5 years is roughly how long
    > each major branch is supported for. That is already clear as could be. I
    > can't quite understand what Jo Rhett is offering to the community that he is
    > upset isn't being taken up. I think he wants some other arbitrary point
    > release to be given extended support, either because in his case 24 months
    > is not enough, or because he wants every release to have 24 months of
    > support, or something else, I'm not sure.


    I think mostly, he just wants to know in advance which releases will
    have 24 months of support.
    Also, it would be very nice if those releases overlapped, so that
    one can jump from one long-tem-support release to the next.

    >
    > Jo, you say that he have had to maintain your own patched build of old
    > FreeBSD releases because you need to keep them in production for longer than
    > EoL period. Can I suggest that the first step is for you to publish those
    > patches somewhere public and allow others to have access to them. Then


    I'll second that.


    -Ben Kaduk


    > you'll have a chance of convincing others to contribute to your patch sets
    > and eventually of convincing FreeBSD to officially sanction them. Go and
    > create a new sourceforge project or convince your boss to set aside some
    > space on his web site/svn server/etc for this project. Tell him that if it
    > goes well, you'll be creating a whole lot of good will for the company in
    > addition to the prospect of getting other people to contribute and share the
    > work.
    >
    >
    > Ari Maniatis
    >
    >
    >
    > [1] http://security.freebsd.org/
    >
    >
    >
    > -------------------------->
    > ish
    > http://www.ish.com.au
    > Level 1, 30 Wilson Street Newtown 2042 Australia
    > phone +61 2 9550 5001 fax +61 2 9550 4001
    > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
    >
    >
    > _______________________________________________
    > freebsd-stable@freebsd.org mailing list
    > http://lists.freebsd.org/mailman/lis...freebsd-stable
    > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
    >

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


  6. Re: Release team resources


    On Mon, 22 Sep 2008, Jo Rhett wrote:

    > I assumed not. I was curious to what extent outside people could help
    > support the process, while leaving commits to the internal people. For
    > example, for everything except the jail vulnerability in the last 4 years
    > the security problems were related to third party utilities, and were widely
    > published in security mailing lists. Someone without a commit bit could
    > certainly build the patch, test the patch on relevant versions, etc.


    I'm not sure I agree with this analysis. From a FreeBSD-centric perspective,
    vulnerabilities fall into four classes:

    - FreeBSD-generated code
    - Third party code blended with out code (arguably ours also)
    - "contrib" code that is in our revision control
    - Ports

    We dropped ports from our advisory scope because the number of vulnerabilities
    skyrocketted due to ports growing and the number of vulnerabilities discovered
    in them growing. We do provide a database of known-vulnerable ports and
    versions, but that's not generally the responsibility of the base security
    team, rather a separate ports security team. I think this is the right
    trade-off -- among our fears is that we over-release advisories, which would
    devalue the usefulness of advisories over time as referring specifically to
    critical issues.

    Extracted from the list of advisories on security.FreeBSD.org going back to
    the beginning of last year:

    Advisory Class
    FreeBSD-SA-08:09.icmp6 Blended
    FreeBSD-SA-08:08.nmount FreeBSD
    FreeBSD-SA-08:07.amd64 FreeBSD
    FreeBSD-SA-08:06.bind Contrib
    FreeBSD-SA-08:05.openssh Contrib
    FreeBSD-SA-08:03.sendfile FreeBSD
    FreeBSD-SA-08:02.libc Blended
    FreeBSD-SA-08:04.ipsec Blended
    FreeBSD-SA-08:01.pty FreeBSD
    FreeBSD-SA-07:10.gtar Contrib
    FreeBSD-SA-07:09.random FreeBSD
    FreeBSD-SA-07:08.openssl Contrib
    FreeBSD-SA-07:07.bind Contrib
    FreeBSD-SA-07:06.tcpdump Contrib
    FreeBSD-SA-07:05.libarchive FreeBSD
    FreeBSD-SA-07:04.file Contrib
    FreeBSD-SA-07:03.ipv6 Blended
    FreeBSD-SA-07:02.bind Contrib
    FreeBSD-SA-07:01.jail FreeBSD

    Counting on my fingers, that's 7 FreeBSD-specific, 4 that lie in code we
    basically maintain, and 8 that are in externally maintained software. Seems
    like a pretty even split. In the case of most third party code
    vulnerabilities, I believe we received non-trivial advanced warning of the
    impending vulnerability announcement.

    > As noted above, very few of the security releases were based on information
    > not available to the general public (who read security-related mailing
    > lists, anyway)


    I'm not sure I agree with this assertion either. While there are exceptions,
    most vulnerabilities are known to the security team in advance of public
    discussion. Depends a bit on which security lists you read, of course...

    Robert N M Watson
    Computer Laboratory
    University of Cambridge
    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  7. Re: Upcoming Releases Schedule...


    On Mon, 22 Sep 2008, Jo Rhett wrote:

    > On Sep 22, 2008, at 12:41 PM, Robert Watson wrote:
    >> Lack of human resources, to use a vile term, is currently the limiting
    >> factor. What happens when that is cleared is another question, but in the
    >> end there aren't a whole lot of paths to greater efficiency here:

    > ...
    >> This is an inherently manual process because security patches touch a
    >> variety of parts of the system and each has different implications, the
    >> tendency for vulnerabilities to come in classes, etc.

    >
    > Great, thanks. Do we have any idea how much additional human resources
    > would be necessary to extend the support period?


    Short answer: no.

    Long answer: we're under-manned for our current commitments, and have seen
    longer advisory cycles than we would like. My guess is that we could eat the
    first 25% of a person just catching up on current obligations so as to reduce
    latency on advisories, handle back-analysis of reports that don't appear to be
    vulnerabilities but we'd like to be sure, etc.

    Another hand-wave: 50%-75% of a person would allow us to move into extending
    our obligations as well as put more resources into proactive work. You don't
    have to be on the security team to work on security work (and many people who
    do aren't), but certainly one obligation that comes with being on the team is
    to try to proactively address vulnerability classes and improve infrastructure
    for issuing advisories, providing updates, etc.

    All hand-waving, understand. Depends a lot on the person, the season (reports
    don't arrive at a constant rate), etc.

    >> because there was significant divergence and maintaining three active
    >> development branches at once (5.x, 6.x, and 7.x) was a serious stretch.

    >
    > I've never suggested maintaining 3 different release versions, and I
    > wouldn't suggest trying. When Sun, Microsoft, et al decide that they don't
    > have the resources to support 3 major revisions, it's a pretty good reason
    > to think that FreeBSD can't either ;-)


    Tricky balance -- if you cut a major release every 18-24 months, you have a
    24-month support cycle on the final point release on each branch, and you
    continue to release minor releases after the .0 of the next branch in order to
    allow .0's to settle for a bit before forcing migration forward, it's hard not
    to end up in the many-branch support game.

    Robert N M Watson
    Computer Laboratory
    University of Cambridge
    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  8. Benefits of multiple release branches (Was: Re: Upcoming ReleasesSchedule...)

    Dylan Cochran wrote:
    > One of the biggest (and most prominent, though not obviously so)
    > issues is the lack of concurrency with regards to releases. With the
    > default system, having multiple freebsd releases side by side (both
    > different versions, and different architectures) is infeasible. This
    > makes the choice more critical, while hindering flexibility. The
    > necessity of long support schedules is one of the symptoms.


    While on the one hand I can understand the users' frustration on this
    point, IMO having at least 2 release branches is necessary. We are
    trying to walk the fine line between pleasing those who want new
    features (including new drivers), better performance, etc. that a newer
    release branch offers (in this case 7.x) and those that want long-term
    API stability, and other forms of stability that an "established"
    release offers. The only practical way to accomplish both of those goals
    is with 2 release branches.

    Speaking only for myself,

    Doug

    --

    This .signature sanitized for your protection
    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  9. Re: Upcoming Releases Schedule...


    On Mon, 22 Sep 2008, Robert Watson wrote:

    >> I think you are using "last release" in a different way. "the last
    >> release" is always the most release release. Right now 6.3 will have
    >> support for longer than 6.4 will, which is the nature of the problem I
    >> raised. If you always supported the most recent release for 24 months then
    >> we wouldn't have any problem.

    >
    > My calendar disagrees with you on this point -- 18 months from September,
    > 2008, is after 24 months from January, 2008. And I think it's much more
    > likely the release will go out in October.


    .... but the wrong calendar -- I was using 18 rather than 12 months, not sure
    where that came from.

    >> I mean seriously, if you were to say "We will support 6.4 for 24 months
    >> *unless* we find it necessary to release 6.5 then I'd be totally happy. But
    >> that's not what is being said.

    >
    > I think we pretty much are saying that: whatever the final release is will
    > be supported for 24 months. 6.4 will likely be it on 6.x, but we're not
    > 100% committed to that being the final decision because we want to see 7.1
    > shake out well.


    The key point here holds, however: I think we should not ever be in the
    position of telling people that support lifetime on a release has been
    reduced.

    Robert N M Watson
    Computer Laboratory
    University of Cambridge
    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  10. Re: Benefits of multiple release branches (Was: Re: UpcomingReleases Schedule...)

    On Mon, Sep 22, 2008 at 5:37 PM, Doug Barton wrote:
    > Dylan Cochran wrote:
    >> One of the biggest (and most prominent, though not obviously so)
    >> issues is the lack of concurrency with regards to releases. With the
    >> default system, having multiple freebsd releases side by side (both
    >> different versions, and different architectures) is infeasible. This
    >> makes the choice more critical, while hindering flexibility. The
    >> necessity of long support schedules is one of the symptoms.

    >
    > While on the one hand I can understand the users' frustration on this
    > point, IMO having at least 2 release branches is necessary. We are
    > trying to walk the fine line between pleasing those who want new
    > features (including new drivers), better performance, etc. that a newer
    > release branch offers (in this case 7.x) and those that want long-term
    > API stability, and other forms of stability that an "established"
    > release offers. The only practical way to accomplish both of those goals
    > is with 2 release branches.


    I agree completely. My point is that as of right now, there is a large
    degree of collisions that take place, that prevent an install of
    6.3-RELEASE and 7.0-RELEASE from existing at the same time on the same
    drive, and being trivial to switch between the two if need be. Same as
    with i386/amd64.

    This is an artificial construct, and doesn't /have/ to continue
    existing. Which imo, will be far more useful then expecting a large
    amount of time expended to dead-end branches of code that are well
    past their expiration date, and begin suffering from massive bitrot.

    At the very least, it will make the default system more robust by
    moving the majority of the upgrade procedure from being /replacements/
    of files, to creating new files coupled with an atomic activation
    'switch'.

    Please don't misinterpret my ideas as being supporting his viewpoint,
    merely pointing out a perspective to the problem which hasn't been
    mentioned.
    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  11. Re: Upcoming Releases Schedule...

    On Mon, 22 Sep 2008, Jo Rhett wrote:
    > On Sep 21, 2008, at 1:57 AM, Robert Watson wrote:
    > > This is precisely what we already do -- we guarantee we will support the
    > > last release on a branch for 24 months after the release. The point of
    > > concern being discussed is that we can't tell you for sure which minor
    > > release will be the last release at the time that release goes out the
    > > door, because the extent to which we keep releasing on old branches depends
    > > in large part on how the new branch looks.

    >
    > I think you are using "last release" in a different way. "the last release"
    > is always the most release release. Right now 6.3 will have support for
    > longer than 6.4 will, which is the nature of the problem I raised. If you
    > always supported the most recent release for 24 months then we wouldn't have
    > any problem.


    Jo, it seems to be you who are trying to use "last" in an unusual way.
    The "last release on a branch" is not the latest one, but the last one.
    For 4.x that was .11 and for 5.x it was .5, where last means just that.

    > I mean seriously, if you were to say "We will support 6.4 for 24 months
    > *unless* we find it necessary to release 6.5 then I'd be totally happy. But
    > that's not what is being said.


    I believe that's exactly what has been said. rwatson@ and simon@ have
    both made it exceedingly clear, to me anyway, that if 6.4 is to be the
    last release on the 6.x branch - as appears to be likely but cannot be
    stated definitely at this time, for reasons clearly given and understood
    - then it will indeed be supported for 24 months.

    It doesn't seem reasonable to expect 24 months stated support for 6.4 if
    it turns out not to be the last release - that would then apply to 6.5.

    It also doesn't seem reasonable to expect that decision to be rushed in
    advance of the necessary evaluation of the success or otherwise of both
    6.4 and 7.1 releases - especially when we're talking about these being
    only a month or so away anyway.

    While I do thank Robert and others for the level of patient detail gone
    into to explain all of this and other aspects of release and security
    engineering to you, me and everyone else, I rather hope re@ can be let
    alone to get on with the real work, beyond this 90+ message thread ..

    my 1.1%, Ian
    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2