We're about to start the release cycle for FreeBSD-7.1 and FreeBSD-6.4.
The proposed schedule for the "major events" of the cycle is:
Freeze August 29
BETA September 1
Branch September 6
6.4-RC1 September 8
7.1-RC1 September 15
6.4-RC2 September 22
7.1-RC2 September 29
6.4-REL October 6
7.1-REL October 13
I haven't posted the schedule on the Web site yet, I'll try to get that
done over the weekend.
On Monday I'll switch RELENG_7 and RELENG_6 over to say they are
7.1-PRERELEASE and 6.4-PRERELEASE respectively as a heads-up that there
will likely be higher-than-normal developer activity MFC-ing stuff
before code freeze starts. Odds get higher that if you do updates using
RELENG_7/RELENG_6 branches during this period you *might* wind up with a
tree that isn't quite right because you happened to catch it part way
through a developer doing a multi-step commit.
We had been procrastinating on saying definitively whether we thought
6.4-REL would be the last of the RELENG_6 releases to see how well
things went with 7.X (if 7.0-REL was a total disaster we'd have
considered doing a 6.5-REL). It seems that 7.0-REL went well and
RELENG_7 in general seems to be in good shape so we now expect 6.4-REL
to be the last of the RELENG_6 releases.
Thanks.
--
Ken Smith
- From there to here, from here to | kensmith@cse.buffalo.edu
there, funny things are everywhere. |
- Theodore Geisel |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080822/dce5890c/attachment.pgp
Ken Smith wrote:> We're about to start the release cycle for FreeBSD-7.1 and FreeBSD-6.4. > The proposed schedule for the "major events" of the cycle is: > > Freeze August 29 > BETA September 1 > Branch September 6 > 6.4-RC1 September 8 > 7.1-RC1 September 15 > 6.4-RC2 September 22 > 7.1-RC2 September 29 > 6.4-REL October 6 > 7.1-REL October 13*snip* In 25 words or less, what are the major changes in 7.0->7.1 and 6.3->6.4 for us end users? //Svein
On Sun, Aug 24, 2008 at 01:45:08AM +0200, Svein Skogen wrote:> In 25 words or less, what are the major changes in 7.0->7.1 and 6.3->6.4 > for us end users?In more words, but pretty interesting: http://people.freebsd.org/~bmah/relnotes/6-STABLE/relnotes-i386.html http://people.freebsd.org/~bmah/relnotes/7-STABLE/relnotes.html Eugene Grosbein
Where can one find the expected EoL for these releases? I've poked around the website and can't find any notes mentioning this, although several people have been making posts suggesting that people should review the EoL schedule when planning their upgrades. On Aug 22, 2008, at 5:51 AM, Ken Smith wrote:> We're about to start the release cycle for FreeBSD-7.1 and > FreeBSD-6.4. > The proposed schedule for the "major events" of the cycle is: > > Freeze August 29 > BETA September 1 > Branch September 6 > 6.4-RC1 September 8 > 7.1-RC1 September 15 > 6.4-RC2 September 22 > 7.1-RC2 September 29 > 6.4-REL October 6 > 7.1-REL October 13 > > I haven't posted the schedule on the Web site yet, I'll try to get > that > done over the weekend. > > On Monday I'll switch RELENG_7 and RELENG_6 over to say they are > 7.1-PRERELEASE and 6.4-PRERELEASE respectively as a heads-up that > there > will likely be higher-than-normal developer activity MFC-ing stuff > before code freeze starts. Odds get higher that if you do updates > using > RELENG_7/RELENG_6 branches during this period you *might* wind up > with a > tree that isn't quite right because you happened to catch it part way > through a developer doing a multi-step commit. > > We had been procrastinating on saying definitively whether we thought > 6.4-REL would be the last of the RELENG_6 releases to see how well > things went with 7.X (if 7.0-REL was a total disaster we'd have > considered doing a 6.5-REL). It seems that 7.0-REL went well and > RELENG_7 in general seems to be in good shape so we now expect 6.4-REL > to be the last of the RELENG_6 releases. > > Thanks. > > -- > Ken Smith > - From there to here, from here to | kensmith@cse.buffalo.edu > there, funny things are everywhere. | > - Theodore Geisel | >-- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Robert Watson wrote:> When it comes to commercial OS products, like Windows and Mac OS X, > there is often a strict requirement to live on the most recent minor > release in order to continue to receive support. For example, you won't > make a lot of headway turning up at Apple and demanding security updates > for Mac OS X 10.5.0 a year after it has been released. The answer will > be "Great, update 10.5.3" (or something along those lines) -- not only > will it fix the security issues, but it will support the hardware we now > sell. In that sense, we're actually quite different: rather than saying > "Sorry, 6.2 is vulnerable, please upgrade to 6.3", we say "You can live > on 6.2 for up to 18 months and receive *only* security and critical > errata patches". > > 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. I really wouldn't mind being told to upgrade from 7.2 to 7.4_p12 because its been 20 months since the last 7.x release. Because companies are used to the Apple and Microsoft way you outlined above, I don't think they'd have a huge problem with it either. Wouldn't it make it easier on the teams to only ofter extended support for the major versions, rather than trying to support specific minor versions (6.3, 6.4, 7.0, 7.1) for an extended time? I'll admit, in the early days of 5.x, I really didn't like having to jump between minor versions. Let's face it, things didn't really settle down until, what, 5.3? In those days, being able to stay on a specific minor release was a Good Thing. However, I don't have the same kind of API and upgrade fear going from 6.x to 6.y. Maybe there are people out there who truly fear upgrading from 6.3 to 6.4, and need both supported for an extended time. But if resources are limited, it seems that only offering extended support for the latest release from a major branch would be the way to go. Perhaps 6-12 months for a minor release, 24+ months for the entire major release train? I'm not demanding anything, or saying this is the right way. I'm just wondering if there is a compromise out there that would give companies the security that their 6.x or 7.x server will have 2 years+ of support for vulnerabilities, while at the same time not requiring the developers to extended support for multiple minor releases. I'll now go put on my asbestos undergarments and sit in the corner. ;-)
On Sep 20, 2008, at 3:37 AM, Robert Watson wrote:> The tension here is between making promises we can definitely keep > and starting to make promises that we can't. We'd like to err on > the former, rather than latter, side.Yes. This is well understood and I agree with those priorities.> You already identified the end goal: extend support lifetimes. You > placed constraint on how that could be accomplished: you were going > to do the work. What I've done is identified our normal model for > getting from the current starting point (a guy on a mailing list > who, while enthusiastic, hasn't shown us the beef) to the proposed > outcome (a guy on the security-officer team, commit access required > to participate in the support process, etc). Here are the subgoals > I broke it out into:Again, what you are saying makes a lot of sense, and I have no problem with it. We're just missing the crucial bit -- what is it going to take to reach that goal? Regardless of commit bits, etc and such forth. Is 10 hours a week of one person enough? Does it really need 4 people with 10 hours a week? How do we get from here to there? This is where I think we're missing each other. Achieving a commit bit -- sure, no problem with what you have outlined. But you haven't finished the thought enough to confirm whether me having a commit bit would solve the problem we are trying to solve. I mean honestly, is one person with a commit bit and some time enough to solve the problem? I've been involved with enough projects to know that the real answer might be, "no, we actually have all the people we need with commit bits but our infrastructure makes doing this difficult right now".>> If you've seen the appropriate Southpark episode: "Step 3: >> Profit!" "Dude, what's step 2?" > > Let's make sure we understand each other clearly: the reason you're > getting replies using words like "demand" is that it is easy to read > your e-mails in exactly the above light. It is not a stretch to > interpret them as reading, "Put me on the security officer team > without having gone through any of the normal processes used to vet > a new member".Well, I find it really sad that I would refer to a hilarious episode about, of all things, Underpants Gnomes! and you would find some way to read it as a demand. Someone is going pretty far to think that, enough such that I doubt it could be empirically proven, given that I have repeatedly stated that I could give a darn about a commit bit - and that my only goal is to make it easier for businesses like my $EMPLOYER to sustain deployment. And furthermore, over 90-something percent of my questions have only had the goal of acquiring information. Without that information, I'm not even certain that my skillset is what is necessary to improve this situation. Once that information is made public, I may end up looking at it and saying either "this isn't something my skills can contribute to in a worthwhile fashion", "this isn't feasible based on what I know of resources that could be brought to the table", etc etc and such forth. I mean seriously, Robert -- if I wanted to demand something I'd be SoL because I haven't the vaguest clue what to demand. I've facing this high black wall of no information. Nobody (on this side of that wall) can make intelligent decisions about what the right thing to do would be. I'm sorry, there is another way to think about this. Yes, I am "demanding" (not a word I would prefer to use, but...). I would like the release team to be specific about what resource limitations prevent it from from longer support periods for -REL branches. IF and WHEN such information is made available, my $EMPLOYER and a few others would be interested in discussing what resources we could bring to the table to help resolve those resource limitations. At that point we would determine how to best use those resources in a manner that the FreeBSD developers are capable of integrating and sustaining in the long term. (ie what you've outlined in your past two messages)> We can talk about changing the process, but I think you can't > contribute to that conversation constructively without understanding > the process. Simply demanding change (and that's how it reads) > shows a lack of respect for how we got to where we are, and puts > people people on the defensive. Or offensive, in some cases. :-)I've never demanded change. I spent the whole afternoon yesterday rereading every post I've made to this list in the last 6 months, and nothing there demanded anything other than information about the resource limitations that were alluded to but never spelled out. And yes, offensive seems to be the default selection by FreeBSD developers.> If you approach a software company and say "Look, we like your > product, but it would really help us if you supported each minor > release for 24 instead of 18 months, and the way you're going to do > this is put our employee on your security response team", I think > you'd see a lot of raised eyebrows there as well.That's the point. I've never said anything like that. And a software company would totally understand the question as originally phrased. "What resource limitations prevent you from supporting this product for a longer period?" Any company would fairly promptly come back with an answer. FWIW, there are at least 3 companies whose software product is supported on FreeBSD, or with Apache, or various other things because of my integration work for them. We approached them and said "We would like you to support XYZ. What do you need to do this?" The software company chatted with us about it, and everyone decided it was easier to have me do the integration work for them as opposed to paying them more. (other companies we paid for them to do the work, etc) This is how things work. You ask a question, somebody answers the question and you sit and chat about solutions that meet everyone's needs. This situation with FreeBSD has been downright shocking because I've never before in my life been attacked for saying "We need this. How can I help?" -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
On Sep 20, 2008, at 12:04 PM, Gary Palmer wrote:> Actually Robert, to be fair to Jo, I suspect it is more proper to say > "$COMPANY wants extended support lifetimes. What can I, or $COMPANY, > do to help make that happen?". I think its been misinterpreted as > Jo saying "Let me do the work". He has offered to see if his company > will let him help on company time, but I do not believe the constraint > is quite as you phrased it above. The goal is the same, but throw it > open to a wider contraint set - what resources does the project need > to make it happen? Money? Test labs? Server hosting? Twinkies?Exactly. Thank you for phrasing it so very well. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
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?> 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 ;-) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
On Sep 22, 2008, at 1:32 PM, Robert Watson wrote:> 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.Thanks for the detail, and I think we all understand the necessary vagueness. Is "a person" 40 hours a week? So if I could commit 10 hours a week, I'm 1/4 of a person in this context? (assuming there was enough trust/etc that I could even do the work -- just for discussion)> 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. >That's true. I've never been a huge fan of "release often" in production systems ;-) That being said, I was working on Debian when they went through the Woody/Sarge era, and frankly I think that distinct production/ development tracks work even less well so it's not like I have useful advice here ;-) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
On Sep 22, 2008, at 3:46 PM, Robert Watson wrote:> 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.I agree. However, there are other ways of doing this than to create overlapping windows of support. (totally whistling in the wind for a moment) This isn't an absolute number, but what about something like this? (it should probably be rewritten) -REL will be supported for a minimum of 12 months. It will be extended if * if no other release of the major version is planned, it will be extended 12 additional months. (24 total) * if another release is planned, it will be supported for 3 months past the date of the next release. This isn't actually all that much different from the actuality of your existing practice, but it provides a reasonable guideline that a business can understand. It's also always incrementally forward, and doesn't reward a business for staying behind on a previous release - like your existing policy is doing right now. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness