proposed change to support policy for FreeBSD Releases
Some quite lively offline discussion has come to conclusion with the following suggestions to change the support policy. Obviously, this is what we feel would be a good idea, but it's obviously open to discussion and there's nobody demanding anything here. It just seems "better". Old text: Each branch is supported by the Security Officer for a limited time only, and is designated as one of `Early adopter', `Normal', or `Extended'. The designation is used as a guideline for determining the lifetime of the branch as follows. Early adopter Releases which are published from the -CURRENT branch will be supported by the Security Officer for a minimum of 6 months after the release. Normal Releases which are published from a -STABLE branch will be supported by the Security Officer for a minimum of 12 months after the release. Extended Selected releases will be supported by the Security Officer for a minimum of 24 months after the release. Proposed (starting point for discussion for) new text: Each branch is supported by the Security Officer for a limited time only, and is designated as one of `Early adopter', `Normal', or 'Final'. The designation is used as a guideline for determining the lifetime of the branch as follows. Early adopter Releases which are published from the -CURRENT branch will be supported by the Security Officer for a minimum of 6 months after the release. Normal Releases which are published from a -STABLE branch will be supported by the Security Officer for a minimum of 12 months after the release. A release which is not the final minor release of a branch will be additionally supported by a minimum of 6 months past the release date of the succeeding version. For example X.1 will be supported for 12 months or until 6 months past the release date of X.2, whichever comes later. Final The final minor release on a given branch will be supported by the Security Officer for a minimum of 24 months after the release. OBSERVATIONS: 1. This avoids the need for the well-documented chicken-and-egg problem of trying to guess which release is the final release. 2. This is a consistent policy in line with many other vendor policies. 3. This rewards forward movement in the branch. And finally, as I've done the match carefully, 4. It would appear to *reduce* rather than enlarge the support requirements for the security team. Unless a minor release comes out less than 6 months after a previous release, only two versions would ever be supported at the same time. In recent history 3 minor releases in the same branch have been supported more often than not. Example under current policy: 6.5 comes out in July of 2009. For July -> October the security team will need to support 3 releases: 6.3, 6.4 and 6.5. From November 2009 through January 2010 the security team will need to support 6.3 and 6.5, but not 6.4. Revised under the existing policy: Support for 6.3 expires in April of 2009. (more than 12 months past release and 6 months after the release of 6.4). Support for 6.4 expires in January of 2010. Support for 6.5 would expire in July of 2011 or 6 months after the release of 6.6. ^NOTE: this example is probably unfeasible since 6.3 already has a published support period ended in January 2010, but this will prevent a similar occurrence happening in future releases. Note2: This new policy would not change the support period for 6.4 if it is the final release, but it does completely resolve the need to "guess" whether or not it will be the final release. The notable change that I believe will encourage business participation in the testing/evaluation process is that 6.4 is guaranteed to be supported either 24 months, or at least 6 months past the release date of 6.5. (recent history suggests this would be 15-19 months). This encourages businesses to test and evaluate 6.4 NOW, rather than waiting until a decision about the support policy is made. Repeat from the top: nobody is demanding anything. I think this policy would make a lot more sense, and would promote forward movement. Feel free to correct me if we overlooked anything. Thanks. -- 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/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: proposed change to support policy for FreeBSD Releases
freebsd-stable et al ... On Tue, Sep 23, 2008 at 01:37:03PM -0700, Jo Rhett wrote: > Some quite lively offline discussion has come to conclusion with the > following suggestions to change the support policy. Obviously, this > is what we feel would be a good idea, but it's obviously open to > discussion and there's nobody demanding anything here. It just seems > "better". > > Old text: > > Each branch is supported by the Security Officer for a limited time o/ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ O\ whole heap of content sniped for brevity. > > a minimum of 24 months after the release. > > Proposed (starting point for discussion for) new text: > > Each branch is supported by the Security Officer for a limited time > only, and is designated as one of `Early adopter', `Normal', or > 'Final'. The designation is used as a guideline for determining the > lifetime of the branch as follows. > > Early adopter > Releases which are published from the -CURRENT branch will be for support of my hardware and any 'new' machines that might wander by .. i like these two definitions, the clarity of teh time line i mean, Early Adopter / Normal > Normal > Releases which are published from a -STABLE branch will be but, in particular i like this (Final) as a place to find some certainty and a place to plan the next step as regards freebsd upgrade path and future hardware acquisitions .. a safe place to plan and look froward from ... > Final > The final minor release on a given branch will be supported by > the Security Officer for a minimum of 24 months after the release. o/ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ O\ whole heap of contents sniped for brevity. thank you gentle peoples for working out this solution. it has given me some much needed clarity as regards forward moving planning. as well as looking to very clearly simplify the desicion making process as regards, not just, 'which freebsd to use' but when to move and what release to move to. as well as helping with the going forward hardware acquisions processes. not all gifts make good freebsd platforms. it helps to know with some kind of certainty wht hardware is being supported/worked on and still in pre-development stage so to speak. at any rate a good place to start with as regards this whole 'support' business .. makes sence to me .. thanks, gang. keep up teh good work .. very much appreciated most kind regards / appreciations. jonathan -- powered by .. QNX, OS9 and freeBSD -- http://caamora com au/operating system === appropriate solution in an inappropriate world === ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: proposed change to support policy for FreeBSD Releases
jonathan michaels wrote: On Tue, Sep 23, 2008 at 01:37:03PM -0700, Jo Rhett wrote: Some quite lively offline discussion has come to conclusion with the following suggestions to change the support policy. Obviously, this is what we feel would be a good idea, but it's obviously open to discussion and there's nobody demanding anything here. It just seems "better". Thanks for the suggestions, but it might have helped to avoid confusion if you had contacted the FreeBSD security team privately before announcing your ideas here... Final The final minor release on a given branch will be supported by the Security Officer for a minimum of 24 months after the release. thank you gentle peoples for working out this solution. it has given me some much needed clarity as regards forward moving planning. No it hasn't. The FreeBSD Security team hasn't agreed to anything yet. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: proposed change to support policy for FreeBSD Releases
On Sep 23, 2008, at 4:45 PM, Colin Percival wrote: jonathan michaels wrote: On Tue, Sep 23, 2008 at 01:37:03PM -0700, Jo Rhett wrote: Some quite lively offline discussion has come to conclusion with the following suggestions to change the support policy. Obviously, this is what we feel would be a good idea, but it's obviously open to discussion and there's nobody demanding anything here. It just seems "better". Thanks for the suggestions, but it might have helped to avoid confusion if you had contacted the FreeBSD security team privately before announcing your ideas here... I'm sorry, I'm confused. This spawned from an ongoing conversation on this list. Rather than have the dialog spin around, I figured it would be better to post a specific example of what I thought. No it hasn't. The FreeBSD Security team hasn't agreed to anything yet. Yes, absolutely to that. As posted this is my own idea, adjusted some based on input from various others, none of whom are on the freebsd security team. I'd love to hear what the freebsd security team thinks. -- 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/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: proposed change to support policy for FreeBSD Releases
Jo Rhett wrote: Some quite lively offline discussion has come to conclusion with the following suggestions to change the support policy. Obviously, this is what we feel would be a good idea, but it's obviously open to discussion and there's nobody demanding anything here. It just seems "better". [...snip...] Note2: This new policy would not change the support period for 6.4 if it is the final release, but it does completely resolve the need to "guess" whether or not it will be the final release. The notable change that I believe will encourage business participation in the testing/evaluation process is that 6.4 is guaranteed to be supported either 24 months, or at least 6 months past the release date of 6.5. (recent history suggests this would be 15-19 months). This encourages businesses to test and evaluate 6.4 NOW, rather than waiting until a decision about the support policy is made. Repeat from the top: nobody is demanding anything. I think this policy would make a lot more sense, and would promote forward movement. Feel free to correct me if we overlooked anything. Thanks. I read the whole thread about releases schedule and I second your proposed changes. It makes things clear to me and I'll be happy if this concept will be accepted by FreeBSD team. Miroslav Lachman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: proposed change to support policy for FreeBSD Releases
On Tue, 2008-09-23 at 13:37 -0700, Jo Rhett wrote: > Some quite lively offline discussion has come to conclusion with the > following suggestions to change the support policy. Obviously, this > is what we feel would be a good idea, but it's obviously open to > discussion and there's nobody demanding anything here. It just seems > "better". > > Old text: > > Each branch is supported by the Security Officer for a limited time > > only, and is designated as one of `Early adopter', `Normal', or > > `Extended'. The designation is used as a guideline for determining > > the lifetime of the branch as follows. > > > > Early adopter > > Releases which are published from the -CURRENT branch will be > > supported by the Security Officer for a minimum of 6 months after > > the release. > > Normal > > Releases which are published from a -STABLE branch will be > > supported by the Security Officer for a minimum of 12 months after > > the release. > > Extended > > Selected releases will be supported by the Security Officer for > > a minimum of 24 months after the release. > > Proposed (starting point for discussion for) new text: > > Each branch is supported by the Security Officer for a limited time > only, and is designated as one of `Early adopter', `Normal', or > 'Final'. The designation is used as a guideline for determining the > lifetime of the branch as follows. > > Early adopter > Releases which are published from the -CURRENT branch will be > supported by the Security Officer for a minimum of 6 months after the > release. > > > Normal > Releases which are published from a -STABLE branch will be > supported by the Security Officer for a minimum of 12 months after the > release. > A release which is not the final minor release of a branch will > be additionally supported by a minimum of 6 months past the release > date of the succeeding version. For example X.1 will be supported for > 12 months or until 6 months past the release date of X.2, whichever > comes later. > > Final > The final minor release on a given branch will be supported by > the Security Officer for a minimum of 24 months after the release. > > > OBSERVATIONS: > > 1. This avoids the need for the well-documented chicken-and-egg > problem of trying to guess which release is the final release. > > 2. This is a consistent policy in line with many other vendor policies. > > 3. This rewards forward movement in the branch. > > And finally, as I've done the match carefully, > > 4. It would appear to *reduce* rather than enlarge the support > requirements for the security team. Unless a minor release comes out > less than 6 months after a previous release, only two versions would > ever be supported at the same time. In recent history 3 minor > releases in the same branch have been supported more often than not. > > Example under current policy: > > 6.5 comes out in July of 2009. For July -> October the security team > will need to support 3 releases: 6.3, 6.4 and 6.5. From November > 2009 through January 2010 the security team will need to support 6.3 > and 6.5, but not 6.4. > > Revised under the existing policy: > > Support for 6.3 expires in April of 2009. (more than 12 months past > release and 6 months after the release of 6.4). Support for 6.4 > expires in January of 2010. Support for 6.5 would expire in July of > 2011 or 6 months after the release of 6.6. > > ^NOTE: this example is probably unfeasible since 6.3 already has a > published support period ended in January 2010, but this will prevent > a similar occurrence happening in future releases. > > Note2: This new policy would not change the support period for 6.4 if > it is the final release, but it does completely resolve the need to > "guess" whether or not it will be the final release. > > The notable change that I believe will encourage business > participation in the testing/evaluation process is that 6.4 is > guaranteed to be supported either 24 months, or at least 6 months past > the release date of 6.5. (recent history suggests this would be > 15-19 months). This encourages businesses to test and evaluate 6.4 > NOW, rather than waiting until a decision about the support policy is > made. > > Repeat from the top: nobody is demanding anything. I think this > policy would make a lot more sense, and would promote forward > movement. Feel free to correct me if we overlooked anything. Thanks. > Isn't this a non-pragmatic way of looking at this? Currently, as long as there are no serious issues with 6.4, 6.4 will be supported for 24 months from release. This is abundantly clear from both prior history and what secteam say. If there are serious issues, then 6.5 will be cut to address these issues, and it would be a release to address these issues. In this case, the 'only 12 month support' is irrelevant; one would want to migra
Re: proposed change to support policy for FreeBSD Releases
On Tue, 2008-09-23 at 13:37 -0700, Jo Rhett wrote: Normal Releases which are published from a -STABLE branch will be supported by the Security Officer for a minimum of 12 months after the release. A release which is not the final minor release of a branch will be additionally supported by a minimum of 6 months past the release date of the succeeding version. For example X.1 will be supported for 12 months or until 6 months past the release date of X.2, whichever comes later. Final The final minor release on a given branch will be supported by the Security Officer for a minimum of 24 months after the release. On Sep 25, 2008, at 7:53 AM, Tom Evans wrote: Isn't this a non-pragmatic way of looking at this? Currently, as long as there are no serious issues with 6.4, 6.4 will be supported for 24 months from release. This is abundantly clear from both prior history and what secteam say. No, it's not. The secteam has repeatedly said that they don't know yet, and can't know yet, whether or not to support 6.4 for 12 or 24 months. This is the problem I am trying to solve. Guessing at this requires foresight, psychic abilities that nobody has. I believe it's a lot more pragmatic to simply say "we will support it for 24 months *unless* a major problem forces another release" and stop trying to be psychic. To my mind, this entire discussion is bikeshed painting that ends up with semantic arguing about what a 'final' release is. It's not semantics. It's a very serious issue with overlapping support periods that cause businesses to stay back on older releases, which means they contribute no resources to testing new releases. -- 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/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: proposed change to support policy for FreeBSD Releases
Jo Rhett <[EMAIL PROTECTED]> writes: > Each branch is supported by the Security Officer for a limited time > only, and is designated as one of `Early adopter', `Normal', or > Final'. The designation is used as a guideline for determining the > lifetime of the branch as follows. I'm not clear on how this helps. We don't know if there will be a need to produce a 6.5 release, so there's no way to judge whether 6.4 should be designated "final" or not. The only logical answer is to do so, which leaves a substantial chance that there will end up being more than one "final" release on the 6.x line. That's not a particularly desirable situation. In fact, it's worse, because if 6.5 happens, it will probably be because there were problems with 6.4 serious enough that we'd rather people move to 6.5 anyway (at least for critical systems). Be well. Lowell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: proposed change to support policy for FreeBSD Releases
On Sep 25, 2008, at 9:32 AM, Lowell Gilbert wrote: I'm not clear on how this helps. We don't know if there will be a need to produce a 6.5 release, so there's no way to judge whether 6.4 should be designated "final" or not. The only logical answer is to do so, which leaves a substantial chance that there will end up being more than one "final" release on the 6.x line. That's not a particularly desirable situation. In fact, it's worse, because if 6.5 happens, it will probably be because there were problems with 6.4 serious enough that we'd rather people move to 6.5 anyway (at least for critical systems). You are exactly right. I am proposing that we stop trying to guess whether or not it is a final release. A release will be supported until the next release + N months (N is currently being debated I guess) or 24 months if there is no followup release. This effectively solves both of the problems you've very accurately named above. -- 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/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: proposed change to support policy for FreeBSD Releases
Hi, Colin. Any news/thoughts on where we are with this? -- 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/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
