Re: Upcoming Releases Schedule...
On Tuesday 23 September 2008 04:42:13 pm Jo Rhett wrote: John, we're already committed to upgrade to 6.3 (since it will currently be supported longer than 6.4). 6.2 support isn't part of this conversation, it has entirely revolved around support periods for upcoming releases. Then replace 6.2 with 6.3 in my comments. Granted, there's nothing to do with 6.3 until it is EOL'd, but you should still get the general idea. I picked 6.2 just to have a specific example to work with. On Sep 23, 2008, at 1:10 PM, John Baldwin wrote: Jo, so it seems to me that you could just start by maintaining your own set of extended support patches for the FreeBSD releases you care about. I don't think you have to be a committer or secteam@ member to do this. It does mean that you might not be able to fix a bug in, say, 6.2 at the same exact time the advisory goes out at first, but you could take the patch from the advisory and apply it to your local 6.2 tree and then update your cumulative patch (would probably want to use some sort of source code control for this where you basically branch from FreeBSD X.Y where X.Y is a vendor branch of sorts). That would let you build the street cred, as it were, to be able to get the patches directly into FreeBSD more easily. To start with it is probably going to be a bit slow as far as getting things committed directly to FreeBSD proper as it means finding a committer who has the time to test and review your patch and then commit it. However, the Unofficial FreeBSD 6.2 Patchset can be updated more quickly since it is something that would be under your control. Also, doing this will give you insight into exactly what is required to support a release after it is EOL'd in a much more direct fashion than an e-mail thread. -- John Baldwin -- 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] -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
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/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Tue, 23 Sep 2008, Ian Smith wrote: On Mon, 22 Sep 2008, Jo Rhett 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. 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. Let's stop using the word last for the time being and instead circumvent the ambiguity via previous and final, perhaps? Maybe if official documentation were updated to avoid this same ambiguity there'd be less misunderstanding too. -Derek. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 23, 2008, at 12:45 AM, Ian Smith wrote: 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. Have you read any of the existing thread? Right now 6.4 will go out of support 3 months before 6.3. Which might or might not change at some point in the future. Isn't this obviously a fairly major problem for any business or even any person to want to spend any time to test/evaluate/etc 6.4? What I proposed in my message (which you completely ignored) was an incremental support policy that builds on each release, instead of actually promoting the idea of skipping releases. This may not be a good idea -- it was just a toss out there, but it makes a lot more sense than the existing policy. Could you at least respond to the issues raised here? -- 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: Upcoming Releases Schedule...
On Sep 23, 2008, at 12:45 AM, Ian Smith wrote: 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. Let me try to say this one other way. If you want businesses or anyone really who doesn't have unlimited time and energy to help evaluate, test, etc this release prior to it coming out, shouldn't you make it worth their while? Supporting 6.3 for longer than 6.4 doesn't make it worth anyone's time or attention to evaluate 6.4. Which means that it becomes significantly more likely that 6.4 will ship with a major problem that could or should have been caught in pre- release testing. The current policy of not deciding until after the fact for support periods could in fact be implemented with a reasonable policy that doesn't require a psychic to determine the likely failure or not of a release. I've proposed one. I'm sure that there are better ways to say it, but I'd really appreciate it if you guys would take the problem seriously. -- 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: Upcoming Releases Schedule...
Jo, so it seems to me that you could just start by maintaining your own set of extended support patches for the FreeBSD releases you care about. I don't think you have to be a committer or secteam@ member to do this. It does mean that you might not be able to fix a bug in, say, 6.2 at the same exact time the advisory goes out at first, but you could take the patch from the advisory and apply it to your local 6.2 tree and then update your cumulative patch (would probably want to use some sort of source code control for this where you basically branch from FreeBSD X.Y where X.Y is a vendor branch of sorts). That would let you build the street cred, as it were, to be able to get the patches directly into FreeBSD more easily. To start with it is probably going to be a bit slow as far as getting things committed directly to FreeBSD proper as it means finding a committer who has the time to test and review your patch and then commit it. However, the Unofficial FreeBSD 6.2 Patchset can be updated more quickly since it is something that would be under your control. Also, doing this will give you insight into exactly what is required to support a release after it is EOL'd in a much more direct fashion than an e-mail thread. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
John, we're already committed to upgrade to 6.3 (since it will currently be supported longer than 6.4). 6.2 support isn't part of this conversation, it has entirely revolved around support periods for upcoming releases. On Sep 23, 2008, at 1:10 PM, John Baldwin wrote: Jo, so it seems to me that you could just start by maintaining your own set of extended support patches for the FreeBSD releases you care about. I don't think you have to be a committer or secteam@ member to do this. It does mean that you might not be able to fix a bug in, say, 6.2 at the same exact time the advisory goes out at first, but you could take the patch from the advisory and apply it to your local 6.2 tree and then update your cumulative patch (would probably want to use some sort of source code control for this where you basically branch from FreeBSD X.Y where X.Y is a vendor branch of sorts). That would let you build the street cred, as it were, to be able to get the patches directly into FreeBSD more easily. To start with it is probably going to be a bit slow as far as getting things committed directly to FreeBSD proper as it means finding a committer who has the time to test and review your patch and then commit it. However, the Unofficial FreeBSD 6.2 Patchset can be updated more quickly since it is something that would be under your control. Also, doing this will give you insight into exactly what is required to support a release after it is EOL'd in a much more direct fashion than an e-mail thread. -- John Baldwin -- 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: Upcoming Releases Schedule...
On September 19, 2008 09: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? 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 RELENG_X_Y_Z_RELEASE never changes. That tag gives you the same bits that are on the FreeBSD X.Y.Z install CD. RELENG_X_Y is the security branch for FreeBSD X.Y. This branch gets the security updates, and the occasional major bug fix. RELENG_X is the -STABLE development branch for FreeBSD X. -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
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
Re: Upcoming Releases Schedule...
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 20, 2008, at 1:56 PM, Simon L. Nielsen wrote: 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 I asked specifically on this list. First I was told it hadn't been decided. My response was to point out that this makes it very hard for a company to decide to commit resources to test it, if there may never be a reasonable chance for deployment. Then I was told it was 1 year, or perhaps just 6 months if it was ruled to be an unstable version. Either answer is less than 6.3's support period. 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. That would be excellent. As soon as you know if this will be true, I'll be able to convince $EMPLOYER to allow me to spend time testing this release. If its not an extended support release, then it will expire before 6.3 (which is already tested) and thus $EMPLOYER gains no value in the effort. FWIW, this is why I'm in favor of consistent support periods. When you align the business benefit with the community benefit, you can get the business to help improve the community product. (remainder snipped to a different subject line) -- 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: Upcoming Releases Schedule...
On Mon, 22 Sep 2008, Jo Rhett wrote: 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. 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: for each vulnerability, we generally start with the HEAD of the tree working back by age, for each branch identifying: - Whether the vulnerability, or broad class of vulnerabilities, exists - If the same patch applies, whether it fixes all instances of the problem in the next branch as well - Generate commit candidate - Test builds and runs - Generate binary updates - Generate appropriate security advisory information 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. None of us remembers the format string vulnerability's arrival on the scene fondly since it became necessary to modify the compiler to try to mechanically sweep the tree for similar issues, for example. The older a branch, the more likely it is that it requires a different analysis and a different patch, hence the sigh of relief when 5.x fell off the support list -- not because it was a bad branch, but because there was significant divergence and maintaining three active development branches at once (5.x, 6.x, and 7.x) was a serious stretch. long essay elided Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
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. 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. -- 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: Upcoming Releases Schedule...
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
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/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
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. 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. 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. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
Jo Rhett wrote: On Sep 19, 2008, at 9:41 PM, Gary Palmer wrote: 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) Just to be clear, what you are interested in is a longer support period for security patches to be merged into a branch such as RELENG_6_3 (which only has security fixes applied to it now). Is that correct? Assuming that I'm correct on that assumption, I would suggest that you gather a community of people who share a similar interest and quite simply do the work. It should be pretty obvious based on any given security advisory what will need to change, and if you get enough people involved there won't be that much work for any one person or company. There is even a mailing list for this sort of thing, freebsd-eol. It's not very active right now, but that doesn't mean you can't change that. As Robert pointed out, project history is such that those who identify a given need and fill it are generally absorbed into the official canon as it were, so at some point in the future you (pl.) might actually become part of the answer to the more resources questions that you keep insisting on an answer to. I'd also like to point out that there is another chicken-egg problem that has been glossed over in this thread. You have said many times that it's hard for a company to devote resources to testing a given release candidate without knowing in advance how long that release will be supported. Several people (including Robert, who is part of the release team) have said that we can't make a firm conclusion on how long a given release will be supported until we have a pretty good idea how successful a given release will be, which requires people actually testing and using it. Do you see the problem? Finally I would like to suggest that everyone interested in the problems of supporting releases for longer than their announced EOL to please take that discussion to the freebsd-eol list. AFAICT it isn't really on topic for -stable. hth, Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Benefits of multiple release branches (Was: Re: Upcoming Releases Schedule...)
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/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
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/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Benefits of multiple release branches (Was: Re: Upcoming Releases Schedule...)
On Mon, Sep 22, 2008 at 5:37 PM, Doug Barton [EMAIL PROTECTED] 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/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 22, 2008, at 1:54 PM, 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 recent 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. As I understand it, 6.3 will EoL in January of 2010. 6.4 will EoL in October of 2009. This is the head-scratcher that leaves me so very confused, and unable to figure out how to explain this to a businessperson. If it worked as you said -- the latest release is guaranteed 24 months but any previous release support ends at some point after the next release is out, then it's easy to explain to management. Doing this upgrade gives you a minimum of 24 months of support 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. Again, how do you explain that? And how do you explain a 3 month window where 6.3 is supported longer than 6.4? (not trying to be accusative or demanding, it's just a fairly odd situation) -- 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: Upcoming Releases Schedule...
On Sep 22, 2008, at 2:56 PM, Doug Barton wrote: I'd also like to point out that there is another chicken-egg problem that has been glossed over in this thread. You have said many times that it's hard for a company to devote resources to testing a given release candidate without knowing in advance how long that release will be supported. Several people (including Robert, who is part of the release team) have said that we can't make a firm conclusion on how long a given release will be supported until we have a pretty good idea how successful a given release will be, which requires people actually testing and using it. Do you see the problem? Yes, I do. And I'm confused as to why the release cycle is structured to keep this problem going. This is your own chicken and egg, and it's a fairly easy one to solve. Nobody else is creating the chicken and egg for FreeBSD, it's being created by the existing policy. -- 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: Upcoming Releases Schedule...
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
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/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
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/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sat, Sep 20, 2008 at 9:52 PM, Aristedes Maniatis [EMAIL PROTECTED] 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/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Fri, 19 Sep 2008, Jo Rhett wrote: Look, I understand what you're saying here. And I don't discredit or disagree that it shouldn't be handled this way. But what you have addressed is a stepwise integration policy of a developer, and does not address how to get a business to commit those resources. Why? Because you are asking for the business to commit the resources without a goal. No, I'm not saying that FreeBSD has to guarantee anything. We both know that guarantees on open source projects aren't worth much. This whole discussion is about open source guarantees -- after some extensive discussions and careful thinking about available resources, the FreeBSD Project declared a set of guarantees about what FreeBSD versions we would continue to support over time. We tried to be realistic about the level of staffing available, the nature of the vulnerabilities that would arise, and the degree to which conservative highly incremental changes could be used to support a branch long after release. The problem is that the 18 months for all releases + extra time for extended support releases is still a short period of time. 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. What I'm saying is that your scoped outline has no goal. Nothing to even reach for. Except maybe perhaps a commit bit for me. If I had wanted a commit bit, I'm sure I would have one by now. I'm not particularly worried about that. I don't even really care to have one (though I would if that was necessary). But that's the highest goal of your outlined scope. A commit bit. 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: - To really contribute to the discussion about support lifetimes and contribute during non-disclosure periods, you need to be on the security officer team and a FreeBSD committer. The former to you have access to the required information and discussion, the latter so that you can act on it. - To be on the security officer team, you need to be a FreeBSD committer in good standing who has shown both the technical acumen and long-term commitment to the project required to work effectively on that team. Because sensitive information is involved, and because we give the security officer team special privileges in the project to accomplish its task, we select proposed members very carefully. - To be a FreeBSD committer, you need to have show a signficant long-term commitment to the project, the ability to identify and work with a mentor, and build the confidence of the core team that you are a candidate in whom we can place significant trust (direct write access to the source code of a system deploy on literally millions of devices). - To show a significant long-term commitment to the project, you need to identify past work and context for your potential future contributions and find a potential mentor (committer) with whom you have an existing professional relationship. Common examples are things like has worked with you over an extended period to get your work merged, or someone who has been watching your work over time and concluded that they are in a good position to go through the mentoring process with you. 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. 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. :-) There's *nothing* wrong with what you have said. What you have said makes perfect sense from an integration perspective. But I don't think it addresses the issues at hand -- businesses need to have explicit goals and at least a haphazard guess at the requirements to reach those goals before they'll commit resources. If you approach a software company and say Look, we like your product, but it would really help us if
Re: Upcoming Releases Schedule...
On Sat, Sep 20, 2008 at 11:37:25AM +0100, Robert Watson wrote: 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. 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? Rgeards, Gary ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
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. /disclaimer 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
Re: Upcoming Releases Schedule...
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. ;-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
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. 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 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/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
Hi, Jo Rhett wrote: I agree with pretty much everything you've said here, with the obvious exception that I don't know what's involved in the release management process to do as you've said. Also for my own self, rather than resurrect 6.2 I'd personally rather focus on what we could do to extend the support period for 6.4. And other releases going forward. If you want extended support period, you should go for 7.1 If I remember correctly .1 REL is supposed to be the target for all binary programs/drivers. But if your target is not only security fixes, but drivers (included in base) and new features then release is not working for you, right? Because new drivers are never back-ported to release, best they go to -stable, but you are not tracking -stable? As I understand if you track stable then you really do not care about the numbers after the dot - you are using just 6.x or 7.x (or 8.x in future) And 7-stable will not reach EOL at least next 4-5 years. Sorry if you already answer this, but the thread is very long and it's hard to track every mail in it. My simple question is how you plan to benefit if 7.1 have extended EOL? You will stick with 7.1Release (RELENG_7_1) and security patches, or to (RELENG_7) - which include new drivers? I'm asking because you said, that the main problem with EOL is not fixing bugs which you can do fine, but new drivers that are not back-ported. How you think this can be solved? Most business user do not want new driver to be masked as security update? -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Thu, 18 Sep 2008, Jo Rhett wrote: Thank you. If you don't mind I'd prefer to widen the scope a touch because 6.2 will eventually go away, and frankly it is probably better to look forward than to resurrect an unsupported version. So I would probably state: Jo's $EMPLOYER has significant interest in longer support for -REL versions. Enough to fund my time supporting the mainstream project. What would Jo (or anyone else in a similar situation) need to bring to the table in order to provide back to the project? This is the same answer I gave Lowell, but let me expand on it slightly. Our community grants rights (read also: responsibilities) on the basis of credibility in the community. Here's a possible plan: In the first stage, you need to establish credibility with the community as someone able and willing to do the work. You can do this by doing hard bits of the work without getting official sanction by creating an Unofficial security and errata support for EoL'd FreeBSD releases web page. Be very careful to scope the work so that you're not over-committing and there's no misunderstanding of what you're trying to do. Flag certain branches as in support, and for each of those branches, provide pointers to the security advisories and errata patches that you've backported. If you take a branch out of support for your page (are no longer interested in maintaining it), keep the old stuff around for historical reasons, but clearly marked as historical rather than active. This will allow you to gain experience in maintaining security and errata patches for FreeBSD branches (more different than you might think from maintaining patches locally), establish credibility with the community as a whole, but in particular with the FreeBSD developers who are responsible for doing similar work for supported branches. This in turn may convince them that they should invest their time in mentoring you for a FreeBSD commit bit, and potentially join the security or release engineering teams once you've established that you are a member of the developer team who works well with others, does good technical work, and who is in it for the long haul. Some downsides to this approach: (1) It doesn't give the immediate gratification of seeing the official support status extended for releases. However, as you say, you're already doing the work. (2) You don't gain early access to confidential vulnerability information as a member of the security team, so (a) you can't have the patches ready in advance of the advisory, and (b) if there are reports of vulnerabilities in versions you support but the FreeBSD security team doesn't, you might not receive it in a timely manner. However, it accepts the way the project works: we don't provide access to our CVS (SVN) repository to people unless they have a mentor willing to propose them, and that mentor has to argue on the basis of a proven track record that the contribution you will make justify commit access to the tree. Likewise, we don't grant membership to the security team to committers unless they've shown a longer term commitment even than required for a commit bit, shown specific interest and commitment to security support issues, and that have they confidence of the security team that will be able to work with appropriate discretion in protecting the confidential and often critical security information we receive. Don't take this as a personal slight -- none of this says you aren't able to work with others, that you don't have the technical skills, that you don't have the time, aren't willing to make the commitment, or that you lack adequate discretion. Rather, it's saying that the way we evaluate people for participation in the project is that they have a track record of these things in the community. In a largely online and volunteer community, that's the way it works. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
First, I'd like to thank you for taking the time to respond to this seriously. I hope you'll read my reply in the very serious, and not accusative tone it is meant. (I am a little tired and fried at the moment, I may not use the best phrasing. I hope I do.) On Sep 19, 2008, at 4:20 AM, Robert Watson wrote: This is the same answer I gave Lowell, but let me expand on it slightly. Our community grants rights (read also: responsibilities) on the basis of credibility in the community. Here's a possible plan: ... work for supported branches. This in turn may convince them that they should invest their time in mentoring you for a FreeBSD commit bit, and potentially join the security or release engineering teams once you've established that you are a member of the developer team who works well with others, does good technical work, and who is in it for the long haul. Look, I understand what you're saying here. And I don't discredit or disagree that it shouldn't be handled this way. But what you have addressed is a stepwise integration policy of a developer, and does not address how to get a business to commit those resources. Why? Because you are asking for the business to commit the resources without a goal. No, I'm not saying that FreeBSD has to guarantee anything. We both know that guarantees on open source projects aren't worth much. What I'm saying is that your scoped outline has no goal. Nothing to even reach for. Except maybe perhaps a commit bit for me. If I had wanted a commit bit, I'm sure I would have one by now. I'm not particularly worried about that. I don't even really care to have one (though I would if that was necessary). But that's the highest goal of your outlined scope. A commit bit. What's missing? A. A goal B. An assessment of the requirements to reach that goal ...etc To get a business to commit resources to a project there must be an actual goal. And to reach that actual goal there must be both (a) a plan to get there, (b) a reasoned assessment of the effort involved, etc etc and (z) the effort taking place to reach that goal. Obviously (z) matters and perhaps you can say it matters most. But no sane business tries to do (z) without a clear idea of what (a)(b)(...) is. If you've seen the appropriate Southpark episode: Step 3: Profit! Dude, what's step 2? (1) It doesn't give the immediate gratification of seeing the official support status extended for releases. However, as you say, you're already doing the work. I'm honestly confused by this statement, because I can't imagine anything about the proposed work being immediate no matter how it was approached. and that have they confidence of the security team that will be able to work with appropriate discretion in protecting the confidential and often critical security information we receive. Unless the security problem is reported internally within FreeBSD alone (very few problems are) I usually have the security details long before you release patches. I don't see this as much of a hindrance if any. Don't take this as a personal slight -- none of this says you aren't able to work with others, that you don't have the technical skills, that you don't have the time, aren't willing to make the commitment, or that you lack adequate discretion. Rather, it's saying that the way we evaluate people for participation in the project is that they have a track record of these things in the community. In a largely online and volunteer community, that's the way it works. There's *nothing* wrong with what you have said. What you have said makes perfect sense from an integration perspective. But I don't think it addresses the issues at hand -- businesses need to have explicit goals and at least a haphazard guess at the requirements to reach those goals before they'll commit resources. I don't see these problems as being in conflict. In fact, I would personally suggest that most of the resources you need to improve your releases don't need commit bits. I personally have no objection at all to running all patches through another set (or two, or three) of eyeballs. It's a damn good practice ;-) It's unlikely to slow me down one bit. ^^^ you may know more about the resource limitations and why commit bits are necessary to relieve your resource strain. In that situation, please educate me. Or everyone. In particular, I'll be happy to buy you coffee/beer/poison of choice at your leisure if that would make this easier. -- 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: Upcoming Releases Schedule...
From what I've gathered so far... | By Jo Rhett [EMAIL PROTECTED] | [ 2008-09-20 02:46 +0200 ] To get a business to commit resources to a project there must be an actual goal. [1] The FreeBSD project would have to commit resources too. Its community that provides those resources need to see tangible work that is useful to the project before committing any resources to it. And to reach that actual goal there must be both (a) a plan to get there, (b) a reasoned assessment of the effort involved, etc etc and (z) the effort taking place to reach that goal. For (a), (b), and (z), this is where you come in. Define the goal. Make a plan to get there. Assess the effort involved. Convince your employer that (a), (b) and (z) is worth it to him/her and that the result of (z) will convince the FreeBSD project to commit the resources needed to integrate it. If they're happy, start working on (z) and bring it to the FreeBSD project when you think it's ready. If the FreeBSD project has to be involved in (a), (b), or (z), it will have to commit its own resources to the effort. See [1]. Just my humble observation as a fellow FreeBSD user... Regards, Aragon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 19, 2008, at 7:07 PM, Aragon Gouveia wrote: To get a business to commit resources to a project there must be an actual goal. [1] The FreeBSD project would have to commit resources too. Its community Of course. This is what the requirements analysis is ;-) For (a), (b), and (z), this is where you come in. Define the goal. Make a plan to get there. Assess the effort involved. Convince your employer that (a), (b) and (z) is worth it to him/her and that the result of (z) will convince the FreeBSD project to commit the resources needed to integrate it. If they're happy, start working on (z) and bring it to the FreeBSD project when you think it's ready. Of course. If this was something that could be done without working with the freebsd developers, do you think I would put up with this kind of abuse? I'd much rather have something I could just go and do ;-) The issue is that nobody is willing to answer the question: what resources are too limited to provide longer support? How can we help? This the elephant that everyone ignores. To develop a plan, you need to know the limitations. Once those are spelled out, you sit down and try to determine what resources are necessary to achieve a certain goal. Then you find those resources, etc etc... Without input from the current release team extending the support schedule is not possible. -- 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: Upcoming Releases Schedule...
On Fri, Sep 19, 2008 at 10:38 PM, Jo Rhett [EMAIL PROTECTED] wrote: On Sep 19, 2008, at 7:07 PM, Aragon Gouveia wrote: To get a business to commit resources to a project there must be an actual goal. [1] The FreeBSD project would have to commit resources too. Its community Of course. This is what the requirements analysis is ;-) For (a), (b), and (z), this is where you come in. Define the goal. Make a plan to get there. Assess the effort involved. Convince your employer that (a), (b) and (z) is worth it to him/her and that the result of (z) will convince the FreeBSD project to commit the resources needed to integrate it. If they're happy, start working on (z) and bring it to the FreeBSD project when you think it's ready. Of course. If this was something that could be done without working with the freebsd developers, do you think I would put up with this kind of abuse? I'd much rather have something I could just go and do ;-) The issue is that nobody is willing to answer the question: what resources are too limited to provide longer support? How can we help? Jo, I think this is the clearest way you have stated your point yet, and it is quite definitely the crux of the issue: What resources does re@ not have, that releases are supported for these short times? I have never run a release, so I can't be much more specific that ``man-hours'' -- someone else should chime in and say what those hours would be spent on, if they were there. I think this is a great opportunity for the project, and a few pointers for how one could maintain an independent support of older releases would give the rest of us a great resource. -Ben Kaduk ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
2008/9/20 Jo Rhett [EMAIL PROTECTED]: On Sep 19, 2008, at 7:07 PM, Aragon Gouveia wrote: To get a business to commit resources to a project there must be an actual goal. [1] The FreeBSD project would have to commit resources too. Its community Of course. This is what the requirements analysis is ;-) For (a), (b), and (z), this is where you come in. Define the goal. Make a plan to get there. Assess the effort involved. Convince your employer that (a), (b) and (z) is worth it to him/her and that the result of (z) will convince the FreeBSD project to commit the resources needed to integrate it. If they're happy, start working on (z) and bring it to the FreeBSD project when you think it's ready. Of course. If this was something that could be done without working with the freebsd developers, do you think I would put up with this kind of abuse? I'd much rather have something I could just go and do ;-) The issue is that nobody is willing to answer the question: what resources are too limited to provide longer support? How can we help? This the elephant that everyone ignores. To develop a plan, you need to know the limitations. Once those are spelled out, you sit down and try to determine what resources are necessary to achieve a certain goal. Then you find those resources, etc etc... Without input from the current release team extending the support schedule is not possible. -- 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] I have been following this thread for a while now and I've only recently used FreeBSD for the past 1-2 years, so my experience is not so great. But from what I've gathered from reading the mailing lists during the EOL of 4.11, the limited resources are From Kernel Space - Security patches - Drivers (sometimes back porting a 7.x driver to 6.x isn't possible because if missing API or limited API calls that are only available to newer kernels) Base/Core Software - Security Patches Ports (I think the biggest issue in maintaining support) - Ports maintainers have to keep patches for every RELENG thats available. Previously they had to maintain compatibility with 3-4 branches (i can't remember), 4.x, 5.x, 6.x, 7.x. and there is alot (10,000+) ports. - At the moment there is two (i think) 6.x and 7.x, and possible mid next year (2009) there will be 3 (8.x). - Some ports didn't work with 4.x due to missing API calls as well and had to be marked broken if they tried to compile it on a 4.x. This will eventually happen when FreeBSD reaches 8 or 9 and 6 will not have the API calls required. From what I gather, those are the main points in maintaining extended support. 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) Are you after support for a RELENG_X or RELENG_X_Y? What are you expecting from the support? Security only? Drivers? Ports? Please don't get me wrong, it is great that you and your company is willing to put the resources in, but its a huge undertaking maintaining a release. Maybe those questions might clarify to some FreeBSD Developers what you're asking from them. NB: I'm not a FreeBSD developer, but a very happy user that maintains FreeBSD servers for business clients. Regards David N ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
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 :-( Are you after support for a RELENG_X or RELENG_X_Y? What are you expecting from the support? Security only? Drivers? Ports? The answer of similar people in this situation might vary. For our needs, security only is fine. Obviously I'd be willing to assist with an effort that tried to provide more support. -- 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: Upcoming Releases Schedule...
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? 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? 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. Note: I am not up on the internals of modern FreeBSD release engineering and maintenance nor the relationship between staff functions, so I may be barking up the wrong telephone pole. Regards, Gary ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
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/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
Andrew Snow wrote: Another thing that I believe would help: Voting on PRs. Currently a maintainer has no idea if a PR is due to one guy's flakey hardware or if 50 people have had the same problem and are waiting for a fix. For each major problem report, there are probably many people who tried FreeBSD on particular hardware and just silently gave up when it failed. You might even find that people don't even know what a PR is or how to report it. Maybe a dialog during the install telling people about the PR system might be helpful. Ability to vote up on a PR on the freebsd website would give maintainers a tool to see which PRs are affecting the userbase. Andrew - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
Quoting Jo Rhett, who wrote on Wed, Sep 17, 2008 at 09:25:27PM -0700 .. On Sep 17, 2008, at 4:33 PM, Robert Watson wrote: An important factor is whether or not we consider the release a highly maintainable release, and while we have intuitions at the time of release, that's something we can only learn in the first couple of months after it's in production. I don't know of any COTS software house that really does it any differently I understand what you mean, but the statement is blatantly false as stated. Anyone selling software to the US Government *must* specify (or meet, depending) a minimum support period, and must also specify a cost the agency can pay to extend the support period. Not relevant to FreeBSD -- just qualifying the statement as it stands. For the obvious comparison, Solaris versions have well- published release and support periods, usually upwards of 8 years. Obviously they have more resources to do this, I'm just pointing out that the statement you made is incorrect as stated. and I'm not sure you could do it differently -- no one plans to ship a lemon, but once in a while you discover that things don't go as planned. I am amazed at the preposterously large elephant in the room that none of you are willing to address. Watching each of you dance around it would be terribly funny if it didn't affect my job so badly. (and if I wasn't going to have to bail on FreeBSD and go to some crap form of Linux because the FreeBSD developers appear to be unwilling to consider the idea of getting more help) You seem to be *demanding* quite a lot lately. Wilko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Thu, Sep 18, 2008 at 02:46:09PM +0200, Wilko Bulte wrote: Quoting Jo Rhett, who wrote on Wed, Sep 17, 2008 at 09:25:27PM -0700 .. On Sep 17, 2008, at 4:33 PM, Robert Watson wrote: An important factor is whether or not we consider the release a highly maintainable release, and while we have intuitions at the time of release, that's something we can only learn in the first couple of months after it's in production. I don't know of any COTS software house that really does it any differently I understand what you mean, but the statement is blatantly false as stated. Anyone selling software to the US Government *must* specify (or meet, depending) a minimum support period, and must also specify a cost the agency can pay to extend the support period. Not relevant to FreeBSD -- just qualifying the statement as it stands. For the obvious comparison, Solaris versions have well- published release and support periods, usually upwards of 8 years. Obviously they have more resources to do this, I'm just pointing out that the statement you made is incorrect as stated. and I'm not sure you could do it differently -- no one plans to ship a lemon, but once in a while you discover that things don't go as planned. I am amazed at the preposterously large elephant in the room that none of you are willing to address. Watching each of you dance around it would be terribly funny if it didn't affect my job so badly. (and if I wasn't going to have to bail on FreeBSD and go to some crap form of Linux because the FreeBSD developers appear to be unwilling to consider the idea of getting more help) You seem to be *demanding* quite a lot lately. Jo has a point, though. I'm certain he's looked at the situation from the developers' point of view, and in response, I'd recommend others try to look at it from his, even if others consider it silly or unreasonable. It's a frustrating situation, and there's no snap-your-fingers-voila solution for it, other than extending support lifetimes per release. Mark's graphs show release lifetimes are getting shorter, which I doubt Jo would have a problem with, assuming each new release was somehow guaranteed (more or less, cut me some slack) to not break previous releases' binaries and so on. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
Quoting Jeremy Chadwick, who wrote on Thu, Sep 18, 2008 at 06:18:40AM -0700 .. On Thu, Sep 18, 2008 at 02:46:09PM +0200, Wilko Bulte wrote: Quoting Jo Rhett, who wrote on Wed, Sep 17, 2008 at 09:25:27PM -0700 .. On Sep 17, 2008, at 4:33 PM, Robert Watson wrote: An important factor is whether or not we consider the release a highly maintainable release, and while we have intuitions at the time of release, that's something we can only learn in the first couple of months after it's in production. I don't know of any COTS software house that really does it any differently I understand what you mean, but the statement is blatantly false as stated. Anyone selling software to the US Government *must* specify (or meet, depending) a minimum support period, and must also specify a cost the agency can pay to extend the support period. Not relevant to FreeBSD -- just qualifying the statement as it stands. For the obvious comparison, Solaris versions have well- published release and support periods, usually upwards of 8 years. Obviously they have more resources to do this, I'm just pointing out that the statement you made is incorrect as stated. and I'm not sure you could do it differently -- no one plans to ship a lemon, but once in a while you discover that things don't go as planned. I am amazed at the preposterously large elephant in the room that none of you are willing to address. Watching each of you dance around it would be terribly funny if it didn't affect my job so badly. (and if I wasn't going to have to bail on FreeBSD and go to some crap form of Linux because the FreeBSD developers appear to be unwilling to consider the idea of getting more help) You seem to be *demanding* quite a lot lately. Jo has a point, though. I'm certain he's looked at the situation from the developers' point of view, and in response, I'd recommend others try to look at it from his, even if others consider it silly or unreasonable. It's a frustrating situation, and there's no snap-your-fingers-voila solution for it, other than extending support lifetimes per release. Indeed, there is no easy solution. Extending support lifetime takes more resources of course. Wilko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
Maybe I'm missing something here, but it seems like Jo just wants to argue for the sake of arguing. First Jo wrote: No other answer.  But nobody has yet provided what the EoL period is  going to be.  I have no problems with a period being extended ;-)  But  the business needs to know the minimum EoL for a given release to  determine if upgrading to that release is viable. To which Robert Watson replied, giving the minimums asked for: Well, a starting answer is the policy found on http://security.FreeBSD.org/: 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. And yet Jo completely ignored that, and focused in on something completely unrelated: I am amazed at the preposterously large elephant in the room that none of you are willing to address. Watching each of you dance around it would be terribly funny if it didn't affect my job so badly. (and if I wasn't going to have to bail on FreeBSD and go to some crap form of Linux because the FreeBSD developers appear to be unwilling to consider the idea of getting more help) Jo: You know the minimum support period for each release, before it is released. You know what the earliest EoL time will be for each release as it is released. What more do you want? -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Thu, Sep 18, 2008 at 12:25 AM, Jo Rhett [EMAIL PROTECTED] wrote: I understand what you mean, but the statement is blatantly false as stated. Anyone selling software to the US Government *must* specify (or meet, depending) a minimum support period, and must also specify a cost the agency can pay to extend the support period. Not relevant to FreeBSD -- just qualifying the statement as it stands. For the obvious comparison, Solaris versions have well-published release and support periods, usually upwards of 8 years. Obviously they have more resources to do this, I'm just pointing out that the statement you made is incorrect as stated. and I'm not sure you could do it differently -- no one plans to ship a lemon, but once in a while you discover that things don't go as planned. I am amazed at the preposterously large elephant in the room that none of you are willing to address. Watching each of you dance around it would be terribly funny if it didn't affect my job so badly. (and if I wasn't going to have to bail on FreeBSD and go to some crap form of Linux because the FreeBSD developers appear to be unwilling to consider the idea of getting more help) My opinion on this matter may be considered radical, but I do think it should be at least recorded, if not impartially considered. While this problem can't be solved just by extending time with the hope that the resources will be allocated (no offense to your character, but that promise is made by a lot of people, and it doesn't always work out that way; particularly in environments with ingrained and blind politics where the money flows can change based on pride and/or sheer ignorance), it may be advantageous to treat the root causes. 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. The fact that you have to choose, and then to change the choice you must clean up, back up, and create a new environment in order to test on a different release/architecture (release in this context includes kernel, a chroot is incomplete for testing), has two major effects: it hinders users from being able to selectively test newer releases with their software stack/hardware selection, with no adverse (within reason; obviously bugs like disk corruption will still happen) changes that will prevent them from reverting. While it may not please the accountants, cleaning up the namespace and allowing safe concurrency of releases will increase the /legitmate/ feasibility of using FreeBSD on a large scale. Oh, I forgot to mention, this is far from a pipe dream. I have a working environment with this capability, and I use it whenever I am able. This isn't to say it is the only cause, it is one of many, and I would never even claim it was a magic bullet. But it is my opinion that this problem is best solved not by arguing how to work around the symptoms, but to analyze and solve the parent problems that may not be so obvious. There's my two cents on the matter. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 18, 2008, at 5:46 AM, Wilko Bulte wrote: You seem to be *demanding* quite a lot lately. I have demanded nothing. I have made a suggestion or two -- presented the background which pretty much everyone agrees with, made some suggestions about how to improve it. My last post was expressing amusement about watching every developer dance around the topic, skipping over the relevant part -- how do we improve things? We could improve things. We could get more resources. Why not consider the topic? That's not demanding. Check your dictionary. -- 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: Upcoming Releases Schedule...
On Wed, 17 Sep 2008, Jo Rhett wrote: Please stop avoiding even considering what people are offering to you. So far, this conversation has largely consisted of you telling us that you don't like what we're doing and demanding that we change. Let's consider three more productive avenues by which you can offer assistance with the problem of how to increase branch support lifetimes: (1) Become a contributor to the community by developing and maintaining patches against unsupported branches, especially against older releases such as 4.x and 5.x where the branches are open for commits but have fallen out of support status. I can't promise the results will immediately fall into the official project umbrella, but consider Colin Percival's freebsd-update as an example of what can be accomplished by someone outside the project when they find a niche. What started out as an external software project (freebsd-update) is now a core system update tool, and Colin has gone from being a random guy with some code to our security officer. (2) Become a contributor to the community by identifying members of the existing developer team for whom additional funding would enable them to spend more time working on and supporting FreeBSD and providing that funding. Consider approaching the FreeBSD Foundation formally to seek matching grant funding for the project. (3) Become a contributor to the community by working with an existing or new company that provides support for FreeBSD commercially, and discussing with them ways that they could provide support for branches past their official EoL date for the project. Companies like FreeBSD Mall have strong relationships with the project, and in the past have contributed significantly to efforts such as release engineering. It's not hard to imagine a company along those lines using something along th elines of a support subscription to fund community-centered support for branches. And those companies may be able to help you identify developers who can do the work, as well as play an active role in seeking further customers with similar interests. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 18, 2008, at 6:32 AM, Wilko Bulte wrote: Indeed, there is no easy solution. Extending support lifetime takes more resources of course. And my e-mails have always discussed ways to get more resources. Recently we even had a group of people trying to arrange for more explicit corporate support for testing and release process. For some reason unclear to me, not a single developer has stepped up and said Great. Here's how we could use you... The entire concept of getting *more resources* is the elephant in the room that everyone seems intent to avoid considering. Maybe, just maybe, there is some reason why FreeBSD doesn't want more people helping. Or ... something. I haven't the vaguest clue. If there is some reason why getting paid people to work on testing and release cycle is a bad idea, would someone please stand up and explain? -- 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: Upcoming Releases Schedule...
On Sep 18, 2008, at 8:21 AM, Freddie Cash wrote: Maybe I'm missing something here, but it seems like Jo just wants to argue for the sake of arguing. You are missing a lot. You're not reading even half of what I am saying. re: ignored. I don't ignore anything. If something is answered clearly I tend to address topics which aren't resolved. But the section you quoted is your worst example -- If you look at my reply, you'll notice that not only did I not ignore it, I replied to that section with concerns about fluctuating schedules that this document presents. -- 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: Upcoming Releases Schedule...
First, thanks for taking the question seriously ;-) On Sep 18, 2008, at 8:47 AM, Dylan Cochran wrote: problem can't be solved just by extending time with the hope that the resources will be allocated (no offense to your character, but that No offense taken. I would never suggest we do anything based on hope. In my company's specific case, we'd want to work out the details of exactly how much time we'd commit and what our goal was in committing that time. (besides the obvious giving back to the community part which we do anyway) Most of the people that I know personally who are interested in this topic are in similar situations. They would want to discuss the necessary resources to achieve a specific goal, and make specific commitments on the amount of time they could give. I seriously don't know anyone who wanders into any situation saying oh, maybe if I help out the tooth fairy will visit me! ;-) That said, I know little about the multi-architecture problems you present here so I can't offer much other commentary, other than: problem is best solved not by arguing how to work around the symptoms, but to analyze and solve the parent problems that may not be so obvious. I suspect this above statement applies to every problem the release and testing teams have. What is necessary to get consensus to even discuss the issues involved? -- 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: Upcoming Releases Schedule...
On Thu, 18 Sep 2008, Jo Rhett wrote: On Sep 18, 2008, at 6:32 AM, Wilko Bulte wrote: Indeed, there is no easy solution. Extending support lifetime takes more resources of course. And my e-mails have always discussed ways to get more resources. Recently we even had a group of people trying to arrange for more explicit corporate support for testing and release process. For some reason unclear to me, not a single developer has stepped up and said Great. Here's how we could use you... The entire concept of getting *more resources* is the elephant in the room that everyone seems intent to avoid considering. No, we're just waiting for you to go ahead and do it. Maybe, just maybe, there is some reason why FreeBSD doesn't want more people helping. Or ... something. I haven't the vaguest clue. If there is some reason why getting paid people to work on testing and release cycle is a bad idea, would someone please stand up and explain? No, we'd love it if more people were paid to work on things like this, but there are two practical problems: (1) finding people, and (2) paying them. All of us are busy people -- we have jobs, we have houses with mortgages, etc, and those of us who are already spending a lot of time on FreeBSD are probably pretty maxed out without adding more to our plates. You seem to have a lot of energy to burn sending e-mail about how to improve the world, and I think what the rest of us would like to see is that energy get turned to the more practical part of the problem. If you are literally standing there with money that you can't figure out how to spend, contact the FreeBSD Foundation Board with a specific proposal regarding the amount of money and what you're trying to accomplish. Perhaps we can help you identify people who would take the money, companies that might want to be involved, help provide some matching funding, etc. However, it needs to be at least a strawman concrete proposal, because waving hands only gets you so far. And it has to be something worth taking time away from all the other things busy people get up to in life, such as optimizing network stacks, fixing file system bugs, supporting releases, etc, or the endeavour has hurt rather than helped. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 18, 2008, at 12:01 PM, Robert Watson wrote: So far, this conversation has largely consisted of you telling us that you don't like what we're doing and demanding that we change. I'm not sure what is going on in your life to make you so defensive that someone saying I have resources, I can help. Here's the problem I'd like to address makes you think they are demanding. Nobody is demanding anything (that I have seen in this conversation). Take a deep breath, stop taking this personal - which I assume you are when you talk about demanding and let's talk about this. Most of the rest of your post is valid. Let's consider three more productive avenues by which you can offer assistance with the problem of how to increase branch support lifetimes: (1) Become a contributor to the community by developing and maintaining patches against unsupported branches, especially against older releases such as 4.x and 5.x where the branches are open for commits but have fallen out of support status. I can't promise the results will We have no 4.x or 5.x systems nor do we have any interest in maintaining those. So perhaps a good idea, but not something I can help with. I *did* offer to work on maintenance for 6.2, but was told it would be rejected by the developers. Would I extend effort to do exactly what I am talking about -- extending the support lifetime for very recent releases? Absolutely. If its in a form useful for the community as a whole. If I have to do this on my own (what we are doing internally now) then the FreeBSD community leverages nothing from the effort, and we're not changing the resources limitations at all. (2) Become a contributor to the community by identifying members of the existing developer team for whom additional funding would enable them to spend more time working on and supporting FreeBSD and providing that funding. Consider approaching the FreeBSD Foundation formally to seek matching grant funding for the project. We have funded projects, we continue to fund projects. Most of our funding right now is aimed at people who don't have the time to work on it, money or no.But again, funding does not improve the resources problem in most cases. Many $EMPLOYERs find it easier to have an employee allocate 10-20% of their work to a project than to get cash allocations for the same. (3) Become a contributor to the community by working with an existing or new company that provides support for FreeBSD commercially, and discussing Nobody who does FreeBSD support on a paid basis can generally solve the kind of problems we find. I have tried these kind of things in the past with both FreeBSD and Linux, and in every case I was significantly better at finding/fixing/patching bugs than anyone on the team. The ones I could not address (usually device driver issues) the support team could do nothing more than forward a bug report to the developer. And in general, they were less good at including relevant details and debug output than I was. In short, it's a non-op. official EoL date for the project. Companies like FreeBSD Mall have strong relationships with the project, and in the past have contributed significantly to efforts such as release engineering. It's not hard to imagine a company along those lines using something along th elines of a Robert, here we go again. You have given several options, not a single one of which will provide more resources to the release team. The only thing you've successfully done is given me three different ways to eff off and leave you alone. Apparently, more resources is not in your interest. -- 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: Upcoming Releases Schedule...
At 03:11 PM 9/18/2008, Jo Rhett wrote: committing that time. (besides the obvious giving back to the community part which we do anyway) I am not familiar with your company nor any developers that work for you. Perhaps you could elaborate on how you have contributed to FreeBSD ? ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Thu, 18 Sep 2008, Jo Rhett wrote: And my e-mails have always discussed ways to get more resources. Recently we even had a group of people trying to arrange for more explicit corporate support for testing and release process. For some reason unclear to me, not a single developer has stepped up and said Great. Here's how we could use you... The entire concept of getting *more resources* is the elephant in the room that everyone seems intent to avoid considering. On Sep 18, 2008, at 12:22 PM, Robert Watson wrote: No, we're just waiting for you to go ahead and do it. Um, how? I suspect you're being sarcastic, but I'll take this at straight value. I have repeatedly said I could commit X resources, and I know others who are likewise willing to make a proposal for the same with their employer, if our efforts could help improve Y problem. Not a single person, *not one*, has ever taken the proposal seriously enough to sit down and discuss with me what kind of resources are necessary to solve this problem. Seriously, go back and read every reply to me on this or the other thread. Every one says We aren't going to do it. No, we'd love it if more people were paid to work on things like this, but there are two practical problems: (1) finding people, and (2) paying them. At the moment I will only speak for myself, so let's start there. I write code. I do integration and testing for a living. I currently maintain a number of ports, including cfengine -- which I personally added the PKGMGR code to for FreeBSD support. My employer is paying my salary, and is willing to dedicate some of my time to the FreeBSD project as a whole. (already does in fact, on the table is to increase that amount) (1) you've found me and (2) I'm already being paid. There are others in the same situation. All of us are busy people -- we have jobs, we have houses with mortgages, etc, and those of us who are already spending a lot of time on FreeBSD are probably pretty maxed out without adding more to our plates. You seem to have a lot of energy to burn sending e-mail about how to improve the world, and I think what the rest of us would like to see is that energy get turned to the more practical part of the problem. As would I. If we could focus on how to improve the situation which has been very well described, we'd be doing something. I don't think you have any idea how frustrating it has been -- I'm here. I'm ready to help. We need to determine how to do this... and nobody will even discuss the problems with me. (if this was a port or a single component then I'd just go run away and do it myself. But the release process is obviously much more complex and I couldn't possibly replicate it or extend it in any fashion from the outside) If you are literally standing there with money that you can't figure out how to spend, contact the FreeBSD Foundation Board with a specific proposal regarding the amount of money and what you're trying to accomplish. Perhaps we can help you identify people who would take the money, companies that might want to be involved, help provide some matching funding, etc. However, it needs to be at least a strawman concrete proposal, because waving hands only gets you so far. And it has to be something worth taking time away from all the other things busy people get up to in life, such as optimizing network stacks, fixing file system bugs, supporting releases, etc, or the endeavour has hurt rather than helped. From our experience, there is a lot more money than there is people's time to address the problem. (as you note above and in the final sentence here) I'm trying to offer something -- more people, already paid, to provide more assistance. But since this involves the release process, we'd have to be integrated into the effort to be useful. FYI: this message is the first I've seen that is going somewhere good. I hope you'll take what I am saying seriously. I'm going to stop replying to many of the other subthreads because they aren't going anywhere good, and I'm probably replying too often anyway. -- 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: Upcoming Releases Schedule...
On Sep 18, 2008, at 12:25 PM, Mike Tancsa wrote: I am not familiar with your company nor any developers that work for you. Perhaps you could elaborate on how you have contributed to FreeBSD ? This domain is my vanity domain, actually. Well not vanity but the domain I use on the rare occasions when I do paid work for other companies. (used to be a lot more, is significantly less now) And no developers work for me. When I sold out my contract got an explicit no head count ;-) I likey ;-) In my $EMPLOYER the main proposal would be to dedicate more of my time. The others contribute at random, but I don't see that changing much due to their existing commitments. -- 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: Upcoming Releases Schedule...
At 03:39 PM 9/18/2008, Jo Rhett wrote: On Sep 18, 2008, at 12:25 PM, Mike Tancsa wrote: I am not familiar with your company nor any developers that work for you. Perhaps you could elaborate on how you have contributed to FreeBSD ? In my $EMPLOYER the main proposal would be to dedicate more of my time. The others contribute at random, but I don't see that changing much due to their existing commitments. I am sorry, I meant, what have you contributed currently or in the past to FreeBSD ? i.e. what code, or money or physical resources (hardware) or time testing code ? ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 18, 2008, at 9:23 PM, Jo Rhett wrote: On Sep 18, 2008, at 12:01 PM, Robert Watson wrote: Let's consider three more productive avenues by which you can offer assistance with the problem of how to increase branch support lifetimes: (1) Become a contributor to the community by developing and maintaining patches against unsupported branches, especially against older releases such as 4.x and 5.x where the branches are open for commits but have fallen out of support status. I can't promise the results will We have no 4.x or 5.x systems nor do we have any interest in maintaining those. So perhaps a good idea, but not something I can help with. I *did* offer to work on maintenance for 6.2, but was told it would be rejected by the developers. Would I extend effort to do exactly what I am talking about -- extending the support lifetime for very recent releases? Absolutely. If its in a form useful for the community as a whole. Are you seriously insisting that a minor release should be supported for more than a year? I think that's pretty exceptional already for any piece of software, and yet you want to extend that? I don't know what your line of work demands, but maybe you're not as constrained as you think you are? The support lifetime of FreeBSD 6 (the major release) is estimated to be up to somewhere in 2010, according to the release information, which seems to satisfy your needs. To me this is a rhetorical question only, I have no way to apply any answers I get to these questions. I'm not involved in the FreeBSD project or in your line of work, I'm just a humble user and supporter. Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll see there is no forest. !DSPAM:74,48d2afa510139919116692! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 18, 2008, at 12:46 PM, Mike Tancsa wrote: I am sorry, I meant, what have you contributed currently or in the past to FreeBSD ? i.e. what code, or money or physical resources (hardware) or time testing code ? I do a lot of testing and patches regarding components we use. Search the PRs. I maintain several ports. I built freebsd package management into cfengine, and greatly extended the package management functionality above and beyond to support every operation freebsd can take on a package. We host numerous freebsd developers in our facility for nearly nothing. We pay for development of features that we need but don't have the appropriate skills to fix ourselves. We sponsor freebsd promotional activity, like the MeetBSD conference coming up this November. In short, we support FreeBSD in every way that I am aware of there is to support it. -- 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: Upcoming Releases Schedule...
Jo Rhett [EMAIL PROTECTED] writes: We have no 4.x or 5.x systems nor do we have any interest in maintaining those. So perhaps a good idea, but not something I can help with. I *did* offer to work on maintenance for 6.2, but was told it would be rejected by the developers. Would I extend effort to do exactly what I am talking about -- extending the support lifetime for very recent releases? Absolutely. If its in a form useful for the community as a whole. If I have to do this on my own (what we are doing internally now) then the FreeBSD community leverages nothing from the effort, and we're not changing the resources limitations at all. I've kind of lost the drift, but it sounds to me as though Jo Rhett is tentatively offering to take on extended support for 6.2, but not earlier versions. Aside from programming skills, what would Jo need to bring to the table in order to provide that back to the project? Is that a reasonable statement of what's on discussion here? [Sorry for putting words into people's mouths, but I need a more concrete discussion in order to be sure I know what anybody actually means.] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
At 04:13 PM 9/18/2008, Jo Rhett wrote: On Sep 18, 2008, at 12:46 PM, Mike Tancsa wrote: I am sorry, I meant, what have you contributed currently or in the past to FreeBSD ? i.e. what code, or money or physical resources (hardware) or time testing code ? I do a lot of testing and patches regarding components we use. Search the PRs. I maintain several ports. I had a search and I see some PRs you have submitted, but I guess you commit under a different @freebsd.org email address ? I built freebsd package management into cfengine, and greatly extended the package management functionality above and beyond to support every operation freebsd can take on a package. We host numerous freebsd developers in our facility for nearly nothing. Thats most excellent! I think people would take your suggestions with greater gravity if you reminded them with a few URLs to point out the various commit messages that say, sponsored by netconsonance etc. Or perhaps a few of these numerous developers could speak up on your behalf? We pay for development of features that we need but don't have the appropriate skills to fix ourselves. That then went back into FreeBSD ? Can you give examples ? I ask all this as you really, really want things to change, and you say you have resources to offer, yet you seem to have alienated a LOT of people from previously similar threads (http://freebsd.monkey.org/freebsd-stable/200806/msg00037.html) You advocate that people not reject your offers of help and resources, yet at the same time respond to developers who actually do a LOT of work and were going to look at what you have to offer by way of bug reports that you are way too busy to oblige http://freebsd.monkey.org/freebsd-stable/200806/msg00069.html Perhaps if you posted some references to success stories you have had with the FreeBSD developer community at large, this would help make your case. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Thu, 18 Sep 2008, Lowell Gilbert wrote: Jo Rhett [EMAIL PROTECTED] writes: We have no 4.x or 5.x systems nor do we have any interest in maintaining those. So perhaps a good idea, but not something I can help with. I *did* offer to work on maintenance for 6.2, but was told it would be rejected by the developers. Would I extend effort to do exactly what I am talking about -- extending the support lifetime for very recent releases? Absolutely. If its in a form useful for the community as a whole. If I have to do this on my own (what we are doing internally now) then the FreeBSD community leverages nothing from the effort, and we're not changing the resources limitations at all. I've kind of lost the drift, but it sounds to me as though Jo Rhett is tentatively offering to take on extended support for 6.2, but not earlier versions. Aside from programming skills, what would Jo need to bring to the table in order to provide that back to the project? Is that a reasonable statement of what's on discussion here? [Sorry for putting words into people's mouths, but I need a more concrete discussion in order to be sure I know what anybody actually means.] What Jo needs to do is what we expect from other participants in the project who want to take on positions of responsibility: build a long-term track record of contributions so that we can trust that when they agree to take on obligations (and we advertise those claims, be it by changing branch lifetimes, accepting WIP feature contributions, etc), they will be fulfilled. Developers offer to mentor new contributors and help shepherd their work when they see that the contributor both has a clear technical contribution to offer *and* that they build necessary rapport and confidence that the investment of time by the mentor is worthwhile. Everyone on this list is a busy person and values their time, and mentoring a developer is a highly non-trivial investment of time, and in most cases, it's a donation of personal time. It is potentially very rewarding, but a lot of work. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Thu, Sep 18, 2008 at 05:03:05PM -0400, Mike Tancsa wrote: At 04:13 PM 9/18/2008, Jo Rhett wrote: On Sep 18, 2008, at 12:46 PM, Mike Tancsa wrote: I am sorry, I meant, what have you contributed currently or in the past to FreeBSD ? i.e. what code, or money or physical resources (hardware) or time testing code ? I do a lot of testing and patches regarding components we use. Search the PRs. I maintain several ports. I had a search and I see some PRs you have submitted, but I guess you commit under a different @freebsd.org email address ? I don't think Jo has a freebsd.org account or mail address. Netconsonance is more or less Jo's own personal/contracting thing, as I understand it, while one of his employers is SVColo (who you WILL see mentioned in commit messages). We pay for development of features that we need but don't have the appropriate skills to fix ourselves. That then went back into FreeBSD ? Can you give examples ? I ask all this as you really, really want things to change, and you say you have resources to offer, yet you seem to have alienated a LOT of people from previously similar threads (http://freebsd.monkey.org/freebsd-stable/200806/msg00037.html) You advocate that people not reject your offers of help and resources, yet at the same time respond to developers who actually do a LOT of work and were going to look at what you have to offer by way of bug reports that you are way too busy to oblige http://freebsd.monkey.org/freebsd-stable/200806/msg00069.html I'm sorry to see that this thread has reached the point where Jo's character has come into question. This path is too commonly taken within this community (read: BSD); the equivalent of doing burn-outs in a parking lot (lots of smoke, zero gain). If Jo's character is truly under scrutiny, be aware that I will stand up for him, as I've interacted with him professionally (read: at my day job, for network outages or other anomalies -- and no, my day job is unrelated to my signature). What surprises me is, sans Robert, everyone seems to be taking what Jo says as a form of flaming, borderline trolling. But in all my years (including on IRC, which should give you some insight to what my definition of troll is), I don't know of anyone who would spend this amount of effort and time discussing an issue at length if they did not have professional and/or personal interest in it. If Jo was just stirring up the ants, this topic wouldn't keep coming up. Likewise, SVColo would not have donated money to meetBSD if they didn't care; and for SVColo to care, that means there's a professional reliance on something (in this case, FreeBSD). Jo is often that representative. I do not deny the mails are heated, and express both frustration and concern, but I don't see anything insulting in them. Possibly this topic could be discussed amongst interested parties at meetBSD. I will be there, and would be more than happy to participate in such a discussion -- or at least take notes. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 18, 2008, at 1:20 PM, Lowell Gilbert wrote: I've kind of lost the drift, but it sounds to me as though Jo Rhett is tentatively offering to take on extended support for 6.2, but not earlier versions. Aside from programming skills, what would Jo need to bring to the table in order to provide that back to the project? Is that a reasonable statement of what's on discussion here? [Sorry for putting words into people's mouths, but I need a more concrete discussion in order to be sure I know what anybody actually means.] Thank you. If you don't mind I'd prefer to widen the scope a touch because 6.2 will eventually go away, and frankly it is probably better to look forward than to resurrect an unsupported version. So I would probably state: Jo's $EMPLOYER has significant interest in longer support for -REL versions. Enough to fund my time supporting the mainstream project. What would Jo (or anyone else in a similar situation) need to bring to the table in order to provide back to the project? -- 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: Upcoming Releases Schedule...
On Sep 18, 2008, at 2:03 PM, Mike Tancsa wrote: I had a search and I see some PRs you have submitted, but I guess you commit under a different @freebsd.org email address ? I don't commit. I submit and others commit. This hasn't really been a handicap ;-) Thats most excellent! I think people would take your suggestions with greater gravity if you reminded them with a few URLs to point out the various commit messages that say, sponsored by netconsonance etc. Or perhaps a few of these numerous developers could speak up on your behalf? Again, netconsonance is Jo and a few random others that contract via the company to avoid having to create their own company. The We in most of my discussions is my $EMPLOYER.And you can see their logos and name listed in numerous places. We pay for development of features that we need but don't have the appropriate skills to fix ourselves. That then went back into FreeBSD ? Can you give examples ? I ask all this as you really, really want things to change, and you say you have \ I'm sorry, but I have neither the time nor the interest in trying to provide a FreeBSD resume to someone. This is a tangent, and never in my experience has a tangent moved the original discussion forward. Are you in a position to make changes? What role in this do you have? What value is there answering these questions? (which have been answered many times if you google for them) I'd rather just drop this tangent. -- 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: Upcoming Releases Schedule...
On Thu, Sep 18, 2008 at 12:23:45PM -0700, Jo Rhett wrote:
On Sep 18, 2008, at 12:01 PM, Robert Watson wrote:
(1) Become a contributor to the community by developing and
maintaining patches against unsupported branches, especially against
older releases such as 4.x and 5.x where the branches are open for
commits but have fallen out of support status. I can't promise the
results will
We have no 4.x or 5.x systems nor do we have any interest in
maintaining those. So perhaps a good idea, but not something I can
help with.
I *did* offer to work on maintenance for 6.2, but was told it would be
rejected by the developers. Would I extend effort to do exactly what
I am talking about -- extending the support lifetime for very recent
releases? Absolutely. If its in a form useful for the community as a
whole.
If I have to do this on my own (what we are doing internally now) then
the FreeBSD community leverages nothing from the effort, and we're not
changing the resources limitations at all.
I don't have a dog in this fight. I'm just writing this message because
it looks to me like there is a lot of talking past one another going on
between people who are basically in violent agreement with one another.
I am hoping that wording things differently will lead to understanding
on both sides. I may have completely misinterpreted both sides. Spoken
languages are too ambiguous.
Here is the boiled down gist of my interpretation of a possible way to
go forward with this; bad pseudo code:
RESOURCES='Jo and the others he seems to know of who back port fixes to
their production versions of unsupported versions of FreeBSD.'
For i in RELENG_X_Y (where X_Y is not a currently supported version of
FreeBSD); do
grant maintenance commit access for $i to ${RESOURCES}
done;
Now for the code documentation:
Maybe one of the ${RESOURCES} could build some web application whereby
people could sign up to be a community extended support resource for
RELENG_X_Y until $date_in_the_future. Perhaps a letter of commitment
from ${RESOURCE}s ${EMPLOYER} would be required before accepting the
candidate for work on RELENG_X_Y.
Then the existing developers or core team could approve their
application/access and provide a mentor if they aren't currently
commiters. (This is some extra work for the existing people. But
hopefully the rewards would be worth the minimal? effort.)
Eventually, the mentor pool could be wholly from ${RESOURCES}. Much
of the approval of new candidates would be from the same pool. The
whole thing might have to be conditional on ${RESOURCES} bringing the
necessary tinderbox type hardware to do basic QA on their extended
support branches. With enough ${RESOURCES} signed up, they might be
able to get hardware from ${DONORS} other than themselves.
The ${RESOURCES} people could gang up on which RELENG_X_Ys they want to
support. They can support them for as long as they have people on the
team who are interested in supporting them. Presumably, these people
would be working for companies which have made a commitment to use
RELENG_X_Y for N years.
In this way, the companies which are already paying their people to
apply security fixes to old releases can donate the work which is
already being done back to the project. Hopefully they will end up
sharing the load so that they reap the benefits of work done by other
companies which are paying people to do the same things.
So long as the requirements for a back port to the ${RESOURCES}
supported branches are the same as to an officially supported branch,
there shouldn't be much chance of harm. Perhaps they are only allowed
to back port fixes which have been approved for a supported RELENG_X_Y.
Eventually, if enough ${RESOURCES} sign up, they might be able to
release X.Y.z distribution media. If they only provide the media for
CD/DVD purchase, the revenue might help to provide for QA tinderboxes
for the ${RESOURCES} supported work.
We might even end up with more people who are familiar with the release
process and volunteer to work on RELENG_X_Y from initial release all
the way through normal end of support and into the community extended
support period.
I think that would provide, as much as is possible, for the don't make
extra work for the existing developers requirement as well as giving
these resources a way to put up or shut up. I could be wrong.
--
Scott LambertKC5MLE Unix SysAdmin
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
Quoting Jo Rhett, who wrote on Thu, Sep 18, 2008 at 11:58:00AM -0700 .. On Sep 18, 2008, at 5:46 AM, Wilko Bulte wrote: You seem to be *demanding* quite a lot lately. I have demanded nothing. I have made a suggestion or two -- presented the background which pretty much everyone agrees with, made some suggestions about how to improve it. My last post was expressing amusement about watching every developer dance around the topic, skipping over the relevant part -- how do we improve things? We could improve things. We could get more resources. Why not consider the topic? That's not demanding. Check your dictionary. I do not need a dictionary thank you very much. Wilko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
I agree with pretty much everything you've said here, with the obvious
exception that I don't know what's involved in the release management
process to do as you've said.
Also for my own self, rather than resurrect 6.2 I'd personally rather
focus on what we could do to extend the support period for 6.4. And
other releases going forward.
In particular, I'd like to highlight what you said here because you've
said very clearly what I've been trying (apparently not so well) to
say for some time now:
In this way, the companies which are already paying their people to
apply security fixes to old releases can donate the work which is
already being done back to the project. Hopefully they will end up
sharing the load so that they reap the benefits of work done by other
companies which are paying people to do the same things.
Thanks.
On Sep 18, 2008, at 3:02 PM, Scott Lambert wrote:
I don't have a dog in this fight. I'm just writing this message
because
it looks to me like there is a lot of talking past one another going
on
between people who are basically in violent agreement with one
another.
I am hoping that wording things differently will lead to understanding
on both sides. I may have completely misinterpreted both sides.
Spoken
languages are too ambiguous.
Here is the boiled down gist of my interpretation of a possible way to
go forward with this; bad pseudo code:
RESOURCES='Jo and the others he seems to know of who back port fixes
to
their production versions of unsupported versions of
FreeBSD.'
For i in RELENG_X_Y (where X_Y is not a currently supported
version of FreeBSD); do
grant maintenance commit access for $i to ${RESOURCES}
done;
Now for the code documentation:
Maybe one of the ${RESOURCES} could build some web application whereby
people could sign up to be a community extended support resource for
RELENG_X_Y until $date_in_the_future. Perhaps a letter of commitment
from ${RESOURCE}s ${EMPLOYER} would be required before accepting the
candidate for work on RELENG_X_Y.
Then the existing developers or core team could approve their
application/access and provide a mentor if they aren't currently
commiters. (This is some extra work for the existing people. But
hopefully the rewards would be worth the minimal? effort.)
Eventually, the mentor pool could be wholly from ${RESOURCES}. Much
of the approval of new candidates would be from the same pool. The
whole thing might have to be conditional on ${RESOURCES} bringing the
necessary tinderbox type hardware to do basic QA on their extended
support branches. With enough ${RESOURCES} signed up, they might be
able to get hardware from ${DONORS} other than themselves.
The ${RESOURCES} people could gang up on which RELENG_X_Ys they want
to
support. They can support them for as long as they have people on the
team who are interested in supporting them. Presumably, these people
would be working for companies which have made a commitment to use
RELENG_X_Y for N years.
In this way, the companies which are already paying their people to
apply security fixes to old releases can donate the work which is
already being done back to the project. Hopefully they will end up
sharing the load so that they reap the benefits of work done by other
companies which are paying people to do the same things.
So long as the requirements for a back port to the ${RESOURCES}
supported branches are the same as to an officially supported branch,
there shouldn't be much chance of harm. Perhaps they are only allowed
to back port fixes which have been approved for a supported
RELENG_X_Y.
Eventually, if enough ${RESOURCES} sign up, they might be able to
release X.Y.z distribution media. If they only provide the media for
CD/DVD purchase, the revenue might help to provide for QA tinderboxes
for the ${RESOURCES} supported work.
We might even end up with more people who are familiar with the
release
process and volunteer to work on RELENG_X_Y from initial release all
the way through normal end of support and into the community extended
support period.
I think that would provide, as much as is possible, for the don't
make
extra work for the existing developers requirement as well as giving
these resources a way to put up or shut up. I could be wrong.
--
Scott LambertKC5MLE Unix
SysAdmin
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
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: Upcoming Releases Schedule...
At 05:46 PM 9/18/2008, Jo Rhett wrote: I'd rather just drop this tangent. Me too. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Tue, Sep 16, 2008 at 04:30:26PM +1000, Andrew Snow wrote: I think FreeBSD is getting in a difficult position now because there's so much cool new stuff being shoe-horned in, but without the necessary volume of contributors to back it up with testing and bug fixes. On Sep 15, 2008, at 11:56 PM, Mark Linimon wrote: We're interested in suggestions about how to get more people involved with testing and bug fixes. There's certainly no lack of demand for the features -- all the way from running on inexpensive wireless routers all the way up to 'enterprise- grade' distributed storage solutions. (These are real examples from various mailing lists.) So, in your opinion, what's the way to reconcile all these demands (features + stability + long-term support of release branches) with a group that is 95%-plus volunteer effort? As I have said to you directly in personal e-mail, the maintenance schedule is creating a chicken and egg problem. If companies weren't forced to run internal distribution and release management on their own, they could allocate more resources (ie volunteers -- PAID ones!) to testing and release management of the main distribution. To speak personally from my own experience: our business can not afford to pay me to help develop a release effort with an unknown maintenance period (6.4-REL). Since we need to have a clear maintenance window for any installed/upgraded host, we are forced to provide that support internally. If we had known (and longer than 12 month) maintenance periods for a given release, then I could avoid maintaining this infrastructure internally and would have somewhere in the neighborhood of 20 hours a month I could dedicate to testing and bug fixes of FreeBSD as a whole. -- 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: Upcoming Releases Schedule...
On Sep 16, 2008, at 12:38 AM, Matthew Seaman wrote: On 'long term support of release branches' -- a volunteer project is always going to struggle to provide this without some form of income to support the necessary hardware and personnel resources needed. Or in other words, if FreeBSD users want the same sort of support structure as they can get from a commercial vendor, it's going to take a commercial vendor to supply it. FreeBSD Corporation anyone? I disagree. The entire advantage of open source is the advantage provided by shared interest in a working product. Each party can put in a little and the product is improved for everyone. If we remove the factors that hamstring companies from providing more resources to assist, then you can get more resources working on the problem - to everyone's benefit. I'm not kidding when I say that nearly everyone I know who uses FreeBSD in their company spends a lot of time managing their internal distribution. (And every reply to this topic on this mailing list has echoed the exact same statement.) None of the ones I know personally have any interest in doing this, and would be happier focusing their effort on the mainstream release. A bunch of us made proposals to our $EMPLOYERs to make this happen, but there was no apparent interest from the release team so the effort was abandoned. -- 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: Upcoming Releases Schedule...
On Mon, 15 Sep 2008, Jo Rhett wrote: Robert, I'd like to point out to you that when I complained about 6.2's accelerated EoL, I was soundly boxed around the ears and told that I should have been paying attention to the projected EoL date when we decided to roll out 6.2 across the business. Now you are saying that expected EoL will be determined at some random point in the future based on gut feelings about how well a completely different branch is doing. How can I reconcile these disparate points of view? How does one focus on testing and upgrade cycle for an appropriately supported release when the decision for the support cycle is completely up in the air? On Sep 16, 2008, at 12:47 PM, Robert Watson wrote: The FreeBSD Project, as with any other company or organization, responds to events as they occur. We try to plan ahead, and when things go better or worse than expected, we sometimes change the plans. As far as I know we've never *shortened* the expected support timeline for any branch or release, but we have on occasion lenthened them when we feel it's important to do so. I'm not sure what other answer is possible. No other answer. But nobody has yet provided what the EoL period is going to be. I have no problems with a period being extended ;-) But the business needs to know the minimum EoL for a given release to determine if upgrading to that release is viable. -- 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: Upcoming Releases Schedule...
On Wed, 17 Sep 2008, Jo Rhett wrote: On Mon, 15 Sep 2008, Jo Rhett wrote: Robert, I'd like to point out to you that when I complained about 6.2's accelerated EoL, I was soundly boxed around the ears and told that I should have been paying attention to the projected EoL date when we decided to roll out 6.2 across the business. Now you are saying that expected EoL will be determined at some random point in the future based on gut feelings about how well a completely different branch is doing. How can I reconcile these disparate points of view? How does one focus on testing and upgrade cycle for an appropriately supported release when the decision for the support cycle is completely up in the air? On Sep 16, 2008, at 12:47 PM, Robert Watson wrote: The FreeBSD Project, as with any other company or organization, responds to events as they occur. We try to plan ahead, and when things go better or worse than expected, we sometimes change the plans. As far as I know we've never *shortened* the expected support timeline for any branch or release, but we have on occasion lenthened them when we feel it's important to do so. I'm not sure what other answer is possible. No other answer. But nobody has yet provided what the EoL period is going to be. I have no problems with a period being extended ;-) But the business needs to know the minimum EoL for a given release to determine if upgrading to that release is viable. Well, a starting answer is the policy found on http://security.FreeBSD.org/: 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. At the time of release, we know if a release is considered early adopter, and attempt to clearly mark it as such. The harder question is whether or not we will start out considering a release normal or extended -- sometimes we are able to make that decision at the time of the release (i.e., we believe firmly it's the last release on the branch at the time of release), but on the whole we will make that decision based on the facts on the ground. An important factor is whether or not we consider the release a highly maintainable release, and while we have intuitions at the time of release, that's something we can only learn in the first couple of months after it's in production. I don't know of any COTS software house that really does it any differently, and I'm not sure you could do it differently -- no one plans to ship a lemon, but once in a while you discover that things don't go as planned. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 17, 2008, at 4:33 PM, Robert Watson wrote: An important factor is whether or not we consider the release a highly maintainable release, and while we have intuitions at the time of release, that's something we can only learn in the first couple of months after it's in production. I don't know of any COTS software house that really does it any differently I understand what you mean, but the statement is blatantly false as stated. Anyone selling software to the US Government *must* specify (or meet, depending) a minimum support period, and must also specify a cost the agency can pay to extend the support period. Not relevant to FreeBSD -- just qualifying the statement as it stands. For the obvious comparison, Solaris versions have well- published release and support periods, usually upwards of 8 years. Obviously they have more resources to do this, I'm just pointing out that the statement you made is incorrect as stated. and I'm not sure you could do it differently -- no one plans to ship a lemon, but once in a while you discover that things don't go as planned. I am amazed at the preposterously large elephant in the room that none of you are willing to address. Watching each of you dance around it would be terribly funny if it didn't affect my job so badly. (and if I wasn't going to have to bail on FreeBSD and go to some crap form of Linux because the FreeBSD developers appear to be unwilling to consider the idea of getting more help) Your limitation is resources, right? You've calculated what you can support based on the resources you have, right? We are talking about ways to increase the resources available to you... right? So the math on which the conclusions are reached then changes. So lets figure out... what do the basis numbers need to be to change the support period? Obviously this is a bit of hand waving. These numbers are unlikely to be empirical. But try. Examine the concept of having increased resources. What do you need. How do you need it, to make a real change? Please stop avoiding even considering what people are offering to you. -- 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: Upcoming Releases Schedule...
Another thing that I believe would help: Voting on PRs. Currently a maintainer has no idea if a PR is due to one guy's flakey hardware or if 50 people have had the same problem and are waiting for a fix. For each major problem report, there are probably many people who tried FreeBSD on particular hardware and just silently gave up when it failed. Ability to vote up on a PR on the freebsd website would give maintainers a tool to see which PRs are affecting the userbase. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
Jo Rhett wrote: Because frankly we're going to be forced to run our own internal release management process instead. I guess this is not surprising, as this appears to be what every other business using significant amounts of freebsd in production are doing today. I'm afraid you've hit the nail on the head. Stable, Current, these words mean nothing to me anymore, I'm using 8-CURRENT to get stable ZFS with the ata driver from 7 (because 8's doesn't work), and the old BTX loader because the new one locks up on all my newer hardware. Then there's the bag of patches I am now carrying around from release to release, some for bug fixes and some for feature enhancements, none of which are in the base system for whatever reason. I think FreeBSD is getting in a difficult position now because there's so much cool new stuff being shoe-horned in, but without the necessary volume of contributors to back it up with testing and bug fixes. There's some truth to what you say, in that I would love to be directly contributing to the FreeBSD effort but instead I feel I'm running around putting out little fires all the time. Plus this era of 4 to 8 CPU cores has meant I am seeing bugs that are difficult to pin down and only occur under production load. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Tue, Sep 16, 2008 at 04:30:26PM +1000, Andrew Snow wrote: I think FreeBSD is getting in a difficult position now because there's so much cool new stuff being shoe-horned in, but without the necessary volume of contributors to back it up with testing and bug fixes. We're interested in suggestions about how to get more people involved with testing and bug fixes. There's certainly no lack of demand for the features -- all the way from running on inexpensive wireless routers all the way up to 'enterprise- grade' distributed storage solutions. (These are real examples from various mailing lists.) So, in your opinion, what's the way to reconcile all these demands (features + stability + long-term support of release branches) with a group that is 95%-plus volunteer effort? mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Mark Linimon wrote: | On Tue, Sep 16, 2008 at 04:30:26PM +1000, Andrew Snow wrote: | I think FreeBSD is getting in a difficult position now because there's | so much cool new stuff being shoe-horned in, but without the necessary | volume of contributors to back it up with testing and bug fixes. | | We're interested in suggestions about how to get more people involved | with testing and bug fixes. | | There's certainly no lack of demand for the features -- all the way from | running on inexpensive wireless routers all the way up to 'enterprise- | grade' distributed storage solutions. (These are real examples from | various mailing lists.) | | So, in your opinion, what's the way to reconcile all these demands | (features + stability + long-term support of release branches) with | a group that is 95%-plus volunteer effort? I think that the FreeBSD project as presently constituted does pretty well on the 'features + stability' side of things -- although it seems the glut of new features coming in at the moment probably is enough for the time being and we need a period of consolidation to restore the balance on the stability side of things. On 'long term support of release branches' -- a volunteer project is always going to struggle to provide this without some form of income to support the necessary hardware and personnel resources needed. Or in other words, if FreeBSD users want the same sort of support structure as they can get from a commercial vendor, it's going to take a commercial vendor to supply it. FreeBSD Corporation anyone? Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. Flat 3 ~ 7 Priory Courtyard PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate ~ Kent, CT11 9PW, UK -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREDAAYFAkjPYpIACgkQ3jDkPpsZ+VbD6gCgwjuVsjPXx9sOc+MzI5yhiG4J XzMAn1wVNZJamCpJejL7WZsjwZ/C8bIF =QnBp -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
Mark Linimon wrote: So, in your opinion, what's the way to reconcile all these demands (features + stability + long-term support of release branches) with a group that is 95%-plus volunteer effort? Its important to me that people keep using FreeBSD. Numbers are important. To that end I'm happy for developers to keep working hardest on the parts of FreeBSD they find most rewarding. Something's got to give and you can't stop it by creating more beaurocracy and red tape. Another thing I think is important is for new hardware to be perpetually sent to those who can implement drivers and create patches. I don't feel the FreeBSD foundation is doing enough in that regard. Not talking about big ticket items like server farms, just new motherboards every time a new CPU or chipset is released. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Tue, Sep 16, 2008 at 06:51:32PM +1000, Andrew Snow wrote: Mark Linimon wrote: So, in your opinion, what's the way to reconcile all these demands (features + stability + long-term support of release branches) with a group that is 95%-plus volunteer effort? Its important to me that people keep using FreeBSD. Numbers are important. To that end I'm happy for developers to keep working hardest on the parts of FreeBSD they find most rewarding. Something's got to give and you can't stop it by creating more beaurocracy and red tape. Another thing I think is important is for new hardware to be perpetually sent to those who can implement drivers and create patches. I don't feel the FreeBSD foundation is doing enough in that regard. Not talking about big ticket items like server farms, just new motherboards every time a new CPU or chipset is released. I agree with the last point. However, a couple counter-points: 1) I believe this is what freebsd-donations@ is for (though I feel the Foundation as a whole could be helping more with this), 2) Based on my own experience: I've offered to purchase new hardware to send developers (free of charge), assuming I can get my hands on whatever hardware it is they need. I'm willing to spend a few hundred dollars to get whatever it is they want, so financially I'm flexible. Here's my experience: What I'm finding out is that it's not the hardware developers need -- it's the time required to sit down and test everything and write the code. No matter what we do, we cannot create more time (or in some cases, more incentives) for developers. What we ultimately need is more talent to make things better. There's a number of people I see doing really good work, at least with regards to RELENG_7 (I do not follow HEAD/CURRENT commits). From what I understand, all these folks are incredibly pressed for time. I'll name names, just because they deserve mention: rwatson, pjd, phk, jhb, alfred, kmacy, kris, kib, yongari, scottl, Andrey Elsukov, and Max Laier. I apologise if I've upset anyone by this -- I'm not naming names to rank people against others (it's a volunteer project after all), I'm just listing off people who I've seen do really good work over the past year or so, with regards to the few devices or kernel pieces I actively follow. For something as gargantuan/massive as an entire operating system and all of its device support, there's a very small number of central people doing regular work. Compare this to Linux, where you've got: a) 6-7 times the amount of kernel-people, b) Commercial interest and support from companies (that means developers are more likely to get documentation and development/test hardware from the vendor themselves), c) A significantly larger user-base for testing. I have never agreed with Eric Raymond's bazaar concept, where the attitude is more eyes = overall better. The problem in our case is not lack of eyes, it's lack of hands and brains. We have a lot of smart people who aren't working on kernel-stuff because they lack the experience/knowledge of how to get involved, where to start, and overall understanding of the code. I'm one of those people, for example. I do not understanding threading (the concept yes, the implementation no), nor any core part of the kernel. The most common rebuttal to this argument is Well, there's this web page and this book, but then when you try to follow either of them, are later told yeah, page is wrong, and book is completely out of date, everything has changed. It's demoralising. I can sit down and within about 15-20 minutes have a minimum understanding of part of a C userland program. Comparatively, I have looked at kernel drivers for hours without any understanding of what numerous kernel ABI/API functions do, why they're being done, why they're being done when they are. I'm not even talking about device-specific semantics (e.g. what does this IC register do, etc.). I'm talking about the surrounding pieces. I *have* hacked on the em(4) driver, but all the surrounding pieces made me say hmm, do not touch. Any time I see the words VFS, BIO, mtx, or uma, I back off. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Mon, 15 Sep 2008, Jo Rhett wrote: On Sep 6, 2008, at 4:06 AM, Robert Watson wrote: Unfortunately, it's a little hard to tell at time-of-release whether a particular release will become extended life or not. This is because extended support status is dependent on the success of the release ... from earlier branch adopters. How long we keep release 6.x releases will depend entirely on how successful 7.x is; I think there's a reasonable expectation that 6.4 or 6.5 will be the last 6.x release, in which case we would want to grant it extended support status. But what happens depends a lot on how successful 7.1 is. My hopes are high, but there's nothing like real-world deployment to shed light on things :-). Robert, I'd like to point out to you that when I complained about 6.2's accelerated EoL, I was soundly boxed around the ears and told that I should have been paying attention to the projected EoL date when we decided to roll out 6.2 across the business. I was also told that I should have been more active in the release cycle process for 6.3, etc. Now you are saying that expected EoL will be determined at some random point in the future based on gut feelings about how well a completely different branch is doing. How can I reconcile these disparate points of view? How does one focus on testing and upgrade cycle for an appropriately supported release when the decision for the support cycle is completely up in the air? The FreeBSD Project, as with any other company or organization, responds to events as they occur. We try to plan ahead, and when things go better or worse than expected, we sometimes change the plans. As far as I know we've never *shortened* the expected support timeline for any branch or release, but we have on occasion lenthened them when we feel it's important to do so. I'm not sure what other answer is possible. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Tue, 16 Sep 2008, Andrew Snow wrote: Mark Linimon wrote: So, in your opinion, what's the way to reconcile all these demands (features + stability + long-term support of release branches) with a group that is 95%-plus volunteer effort? Its important to me that people keep using FreeBSD. Numbers are important. To that end I'm happy for developers to keep working hardest on the parts of FreeBSD they find most rewarding. Something's got to give and you can't stop it by creating more beaurocracy and red tape. Another thing I think is important is for new hardware to be perpetually sent to those who can implement drivers and create patches. I don't feel the FreeBSD foundation is doing enough in that regard. Not talking about big ticket items like server farms, just new motherboards every time a new CPU or chipset is released. The FreeBSD Foundation regular funds hardware purchases for FreeBSD developers, both in terms of individual components and larger purchases; we also play an active role in soliciting donations of larger devices. We recently received a very generous donation of a second Filer from NetApp, which has allowed us to help arrange offsite backup for the FreeBSD.org cluster as part of our general effort to improve contingency planning. As far as I know, we've never once received a request from a developer to, for example, fund the purchases of 20 motherboards of various shapes and sizes to improve test coverage. We do have a specific budget to cover exactly those sorts of requests, and the grant application form is placed fairly prominently on our web site. We've also recently announced a developer project funding programme to contract developers to work on specific projects not served adequately by volunteer or developer time, and hope to announce initial grant recipients in the next few weeks. We've just completed an initial proposal selection and I think you'll find that quite few of the proposed projects are of immediate interest to the larger user community. The Foundation, like the Project, is run largely by volunteers (an all-volunteer board, with the exception of one part-time employee who handles administrative aspects of the Foundation), and therefore experiences exactly the same time limitations as developers do. We drive some initiatives forward directly (such as our Netperf Cluster, a high-performance 10gbps network test environment made possible through a collaboration between the FreeBSD Foundation Sentex Communications, and a number of donors including Cisco, NetApp, FreeBSD Systems, Intel, Chelsio, Myricom, Google, iXSystems, IronPort Systems, and individual donors), but we rely on developers to tell us what they need so that we can fund it or seek donations from potential sponsors. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 5, 2008, at 1:19 PM, Ben Kaduk 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. Extended Selected releases will be supported by the Security Officer for a minimum of 24 months after the release. I don't remember seeing any speculation about 6.4 being an extended release, so, EoL is 12 months after release, whenever that actually happens. Okay, so 6.3 will EoL at roughly the same time as 6.4. Why should anyone spend any effort on 6.4? That's the difference between a long-term-support branch and a regular branch; many OSes do that. If you want to run the same machines for a long time and not have to do a huge battery of tests (at the expense of getting new features and better performance in the interim), you use long-term branches. The regular branches that get released later, will then become unsupported at the same time as the (older) long-term branch. Yes, it's poor when a long-term branch goes EoL before there's another one ready to take its place, but if the new one isn't ready, then you just use whichever regular release is current and then snag a long-term release when it becomes available. Yes, it's more work, but that's life. Is it just me, or does this make no sense at all? This does make it clear to me why the release team can't find the resources to do longer support. Who can convince their company to put resources into the mainstream release effort, when this kind of cycle basically forces every company to run their own internal release process. -- 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: Upcoming Releases Schedule...
On Sep 6, 2008, at 4:06 AM, Robert Watson wrote: Unfortunately, it's a little hard to tell at time-of-release whether a particular release will become extended life or not. This is because extended support status is dependent on the success of the release ... from earlier branch adopters. How long we keep release 6.x releases will depend entirely on how successful 7.x is; I think there's a reasonable expectation that 6.4 or 6.5 will be the last 6.x release, in which case we would want to grant it extended support status. But what happens depends a lot on how successful 7.1 is. My hopes are high, but there's nothing like real-world deployment to shed light on things :-). Robert, I'd like to point out to you that when I complained about 6.2's accelerated EoL, I was soundly boxed around the ears and told that I should have been paying attention to the projected EoL date when we decided to roll out 6.2 across the business. I was also told that I should have been more active in the release cycle process for 6.3, etc. Now you are saying that expected EoL will be determined at some random point in the future based on gut feelings about how well a completely different branch is doing. How can I reconcile these disparate points of view? How does one focus on testing and upgrade cycle for an appropriately supported release when the decision for the support cycle is completely up in the air? How does one talk to management about getting resources assigned to help with the freebsd release testing process, when one cannot make any valid predictions for that release will even be supported long enough to justify the effort involved in upgrading? What you are saying is completely reasonable from a developers point of view. But those of us who use freebsd in an environment which requires extensive testing and long-term planning for support have trouble with this. In short, I can't imagine how I could possibly make any business case to get support for helping the freebsd dev/rel process at all. Why? Because frankly we're going to be forced to run our own internal release management process instead. I guess this is not surprising, as this appears to be what every other business using significant amounts of freebsd in production are doing today. My point to you is that if this wasn't being forced upon every company that uses FreeBSD, those companies could commit more resources to help the core (main branch, whatever - not Core) freebsd development. -- 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: Upcoming Releases Schedule...
On Fri, 5 Sep 2008, Ben Kaduk wrote: To quote from the same website: 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. I don't remember seeing any speculation about 6.4 being an extended release, so, EoL is 12 months after release, whenever that actually happens. Unfortunately, it's a little hard to tell at time-of-release whether a particular release will become extended life or not. This is because extended support status is dependent on the success of the release (i.e., general perception of stability and performance), but also based on the success of other simultaneously releasing branches. We normally don't make a .0 release extended support because there's a reasonable expectation that .0 releases will see more limited deployment than, say, a .1 or .2 release, and that those incrementally later releases will be significantly more stable or performant as a resut of the burn-in the .0 received from earlier branch adopters. How long we keep release 6.x releases will depend entirely on how successful 7.x is; I think there's a reasonable expectation that 6.4 or 6.5 will be the last 6.x release, in which case we would want to grant it extended support status. But what happens depends a lot on how successful 7.1 is. My hopes are high, but there's nothing like real-world deployment to shed light on things :-). Robert N M Watson Computer Laboratory University of Cambridge I thought this was mentioned in the previous thread you started about EoL, but I didn't see it in a quick search. The answer to that is not clear - nor do I know if it should be clear yet. I don't know when the type of support decision is made, but I suspect it's not this early in the process. The release date for 6.4 is ~30 days away, isn't it? Also given that we've previously seen overlaps such that a newer version is only supported to the same EoL as the older version, that would pretty much dictate that spending resources on testing 6.4-REL and/or upgrading would be futile. That's the difference between a long-term-support branch and a regular branch; many OSes do that. If you want to run the same machines for a long time and not have to do a huge battery of tests (at the expense of getting new features and better performance in the interim), you use long-term branches. The regular branches that get released later, will then become unsupported at the same time as the (older) long-term branch. Yes, it's poor when a long-term branch goes EoL before there's another one ready to take its place, but if the new one isn't ready, then you just use whichever regular release is current and then snag a long-term release when it becomes available. Yes, it's more work, but that's life. -Ben Kaduk ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Thu, Sep 4, 2008 at 2:40 PM, Jo Rhett [EMAIL PROTECTED] wrote: Where can one find the expected EoL for these releases? On Wed, Sep 03, 2008 at 09:24:04PM -0700, Nathan Way wrote: http://www.freebsd.org/security/security.html#supported-branches To quote from the above web site: (snip) On Sep 4, 2008, at 6:36 AM, Wesley Shields wrote: These are the existing releases. I believe Jo was looking for EoL for 7.1 and 6.4 once they are released. Yes, thank you. To quote from the same website: 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. I don't remember seeing any speculation about 6.4 being an extended release, so, EoL is 12 months after release, whenever that actually happens. I thought this was mentioned in the previous thread you started about EoL, but I didn't see it in a quick search. The answer to that is not clear - nor do I know if it should be clear yet. I don't know when the type of support decision is made, but I suspect it's not this early in the process. The release date for 6.4 is ~30 days away, isn't it? Also given that we've previously seen overlaps such that a newer version is only supported to the same EoL as the older version, that would pretty much dictate that spending resources on testing 6.4-REL and/or upgrading would be futile. That's the difference between a long-term-support branch and a regular branch; many OSes do that. If you want to run the same machines for a long time and not have to do a huge battery of tests (at the expense of getting new features and better performance in the interim), you use long-term branches. The regular branches that get released later, will then become unsupported at the same time as the (older) long-term branch. Yes, it's poor when a long-term branch goes EoL before there's another one ready to take its place, but if the new one isn't ready, then you just use whichever regular release is current and then snag a long-term release when it becomes available. Yes, it's more work, but that's life. -Ben Kaduk ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Wed, Sep 03, 2008 at 09:24:04PM -0700, Nathan Way wrote: 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. http://www.freebsd.org/security/security.html#supported-branches To quote from the above web site: Branch Release Type Release DateEstimated EoL RELENG_6n/a n/a n/a January 31, 2010 RELENG_6_3 6.3-RELEASE Extended January 18, 2008January 31, 2010 RELENG_7n/a n/a n/a last release + 2 years RELENG_7_0 7.0-RELEASE NormalFebruary 27, 2008 February 28, 2009 These are the existing releases. I believe Jo was looking for EoL for 7.1 and 6.4 once they are released. The answer to that is not clear - nor do I know if it should be clear yet. I don't know when the type of support decision is made, but I suspect it's not this early in the process. -- WXS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
Where can one find the expected EoL for these releases? On Wed, Sep 03, 2008 at 09:24:04PM -0700, Nathan Way wrote: http://www.freebsd.org/security/security.html#supported-branches To quote from the above web site: (snip) On Sep 4, 2008, at 6:36 AM, Wesley Shields wrote: These are the existing releases. I believe Jo was looking for EoL for 7.1 and 6.4 once they are released. Yes, thank you. The answer to that is not clear - nor do I know if it should be clear yet. I don't know when the type of support decision is made, but I suspect it's not this early in the process. The release date for 6.4 is ~30 days away, isn't it? Also given that we've previously seen overlaps such that a newer version is only supported to the same EoL as the older version, that would pretty much dictate that spending resources on testing 6.4-REL and/or upgrading would be futile. To go back to the original statements made at the time: you should consider the lifetime of the release before you invest resources in it. That means we need to know the lifetime to determine how much resources to apply to testing it, yes? -- 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: Upcoming Releases Schedule...
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 BETASeptember 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 | [EMAIL PROTECTED] there, funny things are everywhere. | - Theodore Geisel | -- 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: Upcoming Releases Schedule...
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. http://www.freebsd.org/security/security.html#supported-branches To quote from the above web site: Branch Release Type Release DateEstimated EoL RELENG_6n/a n/a n/a January 31, 2010 RELENG_6_3 6.3-RELEASE Extended January 18, 2008January 31, 2010 RELENG_7n/a n/a n/a last release + 2 years RELENG_7_0 7.0-RELEASE NormalFebruary 27, 2008 February 28, 2009 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
If memory serves me right, Eugene Grosbein wrote: 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 These documents need a fair amount of work towards making them reflect reality. My FreeBSD-related activities have been severely time-constrained for most of this year and I don't see the situation getting much better before these releases ship. :-( For those people who are interested in *helping* with the release notes, patches or inquiries to the doc@ list would probably be appropriate. Cheers, Bruce. signature.asc Description: OpenPGP digital signature
Re: Upcoming Releases Schedule...
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 BETASeptember 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Upcoming Releases Schedule...
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 BETASeptember 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 | [EMAIL PROTECTED] there, funny things are everywhere. | - Theodore Geisel | signature.asc Description: This is a digitally signed message part
