Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
On Sunday 08 June 2008 07:49:35 am Andy Kosela wrote: [ much snippage.. ] there is time to rethink FreeBSD overall strategy and goals. Major companies using FreeBSD in their infrastructure like Yahoo! or Juniper Networks would definetly benefit from such moves focused on long term support of stable releases. I honestly think it is in their interest to support, even financially FWIW, Yahoo! tracks -stable branches, not point releases. -- 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: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
Robert Watson wrote: On Wed, 11 Jun 2008, Anton - Valqk wrote: I fully agree with the lines below. As noticed below there is more attention to developing new features, than making releases rock solid stable. ... Ah, another thing, I'm waiting for virtualization networking layer for jails for quite long. I've tested it on a test server, worked perfect, but on production I don't want to patch my base. there are few other features to jals that never got commited in base, and as I said I don't want to patch it... The reason that the virtualization patches aren't in the tree is precisely *because* we care about stability and are willing to slow down feature development in order to accomplish it. Some features take years to stabilize, and just because a patch works OK in your environment doesn't mean it will work in everyone's. Moderating the rate at which we adopt agressive new features is part of an intentional strategy to avoid letting development trees destabilize to a point where it's unproductive. I totally agree with that point, just commented that it's been year(s) since its appearence an maybe not enought effort in it (just an outsider thought, can't know if it is) and the fueature is a really really great and nice one! 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] -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
Just my 5cents (some thoughts), I fully agree with the lines below. As noticed below there is more attention to developing new features, than making releases rock solid stable. As mentioned in reply posts the 3 branches 6.X 7.X and 8.X takes too many resources and is very hard to support. I, personally, will be waiting for 7.2 release (noticed that .2 over few (3-4 years)) are most stable ones. My main drama with FreeBSD is that ports don't have -SECURITY patches, and if I there is a bug in php I have to rerbuild and populate the latest version. Another _very important_ thing is that there is no binary support to packages that has vulns, and you have to rebuild them from ports. Just a simple example: I have 4-5 fbsd machines and about 15-20 debian stable machines. To administer fbsd machines when there are ports bugs(bugs in ports I use) it takes me at least about 4times more time than update _all_ debian machines... Well...I have other things to do too, too many... now guess what I will choose? I'll use debian, and that's not because I don't have will to use freebsd, it's simply because I do my tasks 4 times slower than when I choose debian. Someone will say FreeBSD is not for you, then back off. That's not the point, I like fbsd, but as more busy I get, as less I'll be able to use it, takes too much of my time. Once I've told that there is no binary support (but I didn't expressed myself correctly). There is no ports VULNS binary support. If there is (and I've never heard of it), I'll be very happy someone to point me out this, because I'll continue running fbsd. Ah, another thing, I'm waiting for virtualization networking layer for jails for quite long. I've tested it on a test server, worked perfect, but on production I don't want to patch my base. there are few other features to jals that never got commited in base, and as I said I don't want to patch it... in linux (debian for me) there is xen that works with 'new' intel hardware virtualization, that's another red point for debian there are other things that I'll leave unsaidso... that's all for now. sorry for my bad english, it's not my native. these are just my thoughts and don't want to force anyone to agree with them, but I'll be happy to read your thoughts on this. cheers, valqk. Andy Kosela wrote: On 6/8/08, Freddie Cash fjwcash at gmail.com wrote: On 6/7/08, Jo Rhett jrhett at netconsonance.com wrote: The question I raised is simply: given the number of bugs opened and fixed since 6.3-RELEASE shipped, why is 6.3 the only supported version? Why does it make sense for FreeBSD to stop supporting a stable version and force people to choose between two different unstable versions? Is this really the right thing to do? Define the terms stable and unstable, how you measure said stability and instability, and what you are comparing them against. This whole discussion is really interesting as it clearly showcases two common trends in computing (rapid development vs stability) On the one side we got people (let's call them developers or computer scientists) who are more interested in development than stabilization of the existing code base. It's natural for them to think more about new features, researching new ideas and implementing them. It resembles an academic project, research project.Those computer scientists do not care much about stability, they are mainly interested in hacking on the code for the fun of it. It is open source after all as someone wisely remarked. From my own experience most if not all community based projects are more interested in following this trend than stabilization of the code. Although they do care about stability of their code base, their focus is more on implementing new features and moving rapidly forward. In today's quickly changing world we see this trend as prevailing. On the other hand though, there is a trend which focuses on maximum long term stabilization of the code base. Usually we see this trend in high end commercial companies serving the needs of mission critical businesses where even a minute of downtime can cause loss of thousands of dollars or even loss of lives of people (imagine stock exchanges, banks, financial insurance institutions, army and police facilities, hospitals, nuclear plants etc.). Those types of businesses/institutions truly needs a maximum stable operating system. They really do not care about new features, but they do care about maximum stability of the existing code, security, and nonstop business continuity even in the face of natural disasters. There is only one operating system I know of that survived 9/11 attacks - this is OpenVMS. It's not uncommon to see VMS uptimes of more than 10 years (you can ask Amsterdam police for evidence). Now that is a true stability! On the other note though, stability is the direct opposition of development and change. Something which is *stable* cannot change or must change very
Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
On Wed, 11 Jun 2008, Anton - Valqk wrote: I fully agree with the lines below. As noticed below there is more attention to developing new features, than making releases rock solid stable. ... Ah, another thing, I'm waiting for virtualization networking layer for jails for quite long. I've tested it on a test server, worked perfect, but on production I don't want to patch my base. there are few other features to jals that never got commited in base, and as I said I don't want to patch it... The reason that the virtualization patches aren't in the tree is precisely *because* we care about stability and are willing to slow down feature development in order to accomplish it. Some features take years to stabilize, and just because a patch works OK in your environment doesn't mean it will work in everyone's. Moderating the rate at which we adopt agressive new features is part of an intentional strategy to avoid letting development trees destabilize to a point where it's unproductive. 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: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
Gary Palmer wrote: I think a large part of the shortcomings of the ports infrastructure when it comes to security releases could be mitigated if there was a rapid building and availability of packages on FTP mirrors to prevent everyone from doing portupgrade -P and then having to wait for the build as the packages don't show up for x days, and people can't wait that long for the fix. I raised that issue recently on freebsd-ports@ and was told that there are no resources for that right now, although everyone agreed that it is definitely something that would be nice-to-have. 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: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
On Mon, Jun 9, 2008 at 3:25 PM, Jo Rhett [EMAIL PROTECTED] wrote: On Jun 8, 2008, at 3:27 PM, Freddie Cash wrote: Like I said, you have to define what you mean by stable and unstable before the discussion can continue. stable can mean many things to many people. You talk about feature stability. Other may talk about number of open bugs as being unstable. Others may talk of API/ABI stability. Other may mean code that don't crash a system. Your view of stable meaning features don't change is no where near my definition of stable (systems that don't crash, and where I can run binaries from older point releases on newer point releases). I don't care about features, I care about uptime. stable in my brain means that there isn't 150 revisions to the cvs tree in the 2 months post release regarding kernel and core drivers. stable is also overloaded with meaning will be around long enough that I can focus on other projects instead of replacing it nearly instantly with a new release FWIW, since you clearly misunderstood my point of view. Actually, I believe you misunderstood me, as you quoted me out of context, and quoted my reply to someone else. :) My message to you was define what you mean by stable and unstable. Which, if I follow correctly, you define as never having any commits to the codebase. I care about uptime as well (along with performance and maintainability). And so far, none of our systems using em(4) cards, bge(4) cards, twa(4) cards, gmirror(8) (although I've since moved those to 7-STABLE with ZFS alongside), running on bare metal or in VMs have any issues with 6.3-RELEASE or 7.0-RELEASE. But, how does the number of commits since release have any bearing on uptime of a system you haven't tested? ;) Those seem to be completely unrelated to me. -- 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: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
On 6/7/08, Jo Rhett [EMAIL PROTECTED] wrote: The question I raised is simply: given the number of bugs opened and fixed since 6.3-RELEASE shipped, why is 6.3 the only supported version? Why does it make sense for FreeBSD to stop supporting a stable version and force people to choose between two different unstable versions? Is this really the right thing to do? Define the terms stable and unstable, how you measure said stability and instability, and what you are comparing them against. Only then can people understand what you are talking about, and can any kind of meaningful dialog occur. Right now, you are saying one thing, people are hearing another, and responding with something else. Oh, and be sure to back things up with actual data, otherwise there's no point in going any further with this. -- 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: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
--On June 8, 2008 1:49:35 PM +0200 Andy Kosela [EMAIL PROTECTED] wrote: FreeBSD has always been known for its legendary stability and mature code base which is why many commercial companies depend on it every day. The anomaly as someone said of long term support for 4.x releases only helped to see FreeBSD as more stable and viable solution than Linux by many businesses. Mission critical systems needs long term support (read: at least backporting security patches) and stable systems that can run for years without interruption. When it comes to stability vs development maybe there is time to rethink FreeBSD overall strategy and goals. Major companies using FreeBSD in their infrastructure like Yahoo! or Juniper Networks would definetly benefit from such moves focused on long term support of stable releases. I honestly think it is in their interest to support, even financially Interesting thoughts. Maybe the time is ripe for a RedHat-like support company for FreeBSD. Paul Schmehl If it isn't already obvious, my opinions are my own and not those of my employer.
Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
--On June 8, 2008 5:49:20 PM +0200 Michel Talon [EMAIL PROTECTED] wrote: I think it is very unreasonable for end users to ask maintaining, e.g. 6.2 ad vitam eternam. The real stable branch is now 7.* and diverting effort to polish the 6.* is a waste of time. People wanting a very stable system should simply use something else, like Debian stable, official RedHat, etc. whose aim is precisely to offer the maximum stability, with only security and bug fixes, and for extended periods of time. The price you pay is obsoleted and unsexy systems, which is probably OK for the intended use. On the other hand i have no business running such a system. Please do understand that for some of us, these are not choices. I wiped a FreeBSD machine and bought and installed RedHat because a vendor's software would only run on RedHat. The experience was a painful one. RedHat's updates are a pure PITA. The box now runs FreeBSD again, and I doubt I will ever experiment with something else again. If I can't have FreeBSD, I won't run a server. I don't think I'm alone. Paul Schmehl If it isn't already obvious, my opinions are my own and not those of my employer.
Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
On 2008-Jun-08 17:49:20 +0200, Michel Talon [EMAIL PROTECTED] wrote: and it is now working perfectly well without any trouble. The only gotcha is the slowness of X problem when compiling, but i live with that. Have you tried SCHED_ULE? In my experience, it does a better job of scdeduling than SCHED_4BSD, even on UP machines (YMMV). which are perhaps susceptible of destabilising it. Personnally i have seen the same occurring with 6.0, 5.0 and 4.*, for me the last releases of the 4.* were very poor on my laptop while the early 4.* releases were perfectly OK. The difficulty with the later 4.x releases was that there were major differences between the 4.x and later kernels and this made it increasingly difficult to backport bugfixes. This is less of an issue with now 4.x is out of the way. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpmjvNkZtFUJ.pgp Description: PGP signature
Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
On Sun, 8 Jun 2008, Andy Kosela wrote: Define the terms stable and unstable, how you measure said stability and instability, and what you are comparing them against. This whole discussion is really interesting as it clearly showcases two common trends in computing (rapid development vs stability) On the one side we got people (let's call them developers or computer scientists) who are more interested in development than stabilization of the existing code base. It's natural for them to think more about new features, researching new ideas and implementing them. It resembles an academic project, research project. ... On the other hand though, there is a trend which focuses on maximum long term stabilization of the code base. Usually we see this trend in high end commercial companies serving the needs of mission critical businesses where even a minute of downtime can cause loss of thousands of dollars or even loss of lives of people (imagine stock exchanges, banks, financial insurance institutions, army and police facilities, hospitals, nuclear plants etc.). Those types of businesses/institutions truly needs a maximum stable operating system. They really do not care about new features, but they do care about maximum stability of the existing code, security, and nonstop business continuity even in the face of natural disasters. I think there are some important truths to your observations, but let me present a contrarian view: I think you are presenting a false dichotomy, unnecessarily pitting developers and users at odds with respect to the goals of the project. There are definitely points of conflict along these lines, but much of the time the reason that people use FreeBSD is precisely because there *is* agreement on these points. There are many FreeBSD developers who work on FreeBSD precisely because their employer uses FreeBSD, and hence directly represent interests of long-term support, stability, etc. And indeed, as you observe, these are the interests of large web hosts, appliance companies, etc, being required to build their products. We have a highly branched development in order to reflect the varying degrees of both investment in and tolerance for different levels of feature development vs. stability. If FreeBSD developers only hung around to do adventurous new feature development, we wouldn't have -STABLE branches, errata/security branches, freebsd-update, and so on. Instead, we have a very large infrastructure and a lot of developer time invested in those areas, and this has been growing over time. For example, we introduced RELENG_X_Y errata/security branches in the 4.x timeframe to better serve communities with a low tolerance for feature change. Prior to that time, users had to directly manage patches themselves if they wanted to avoid sliding forward on -STABLE. Likewise, in the mid-5.x timeframe, we added Perforce so that developers wanting to work on projects with very high levels of instability could do so without disrupting HEAD as much, which both improved the pace of development and lead to a more stable product by avoiding allowing the HEAD to become extremely unstable. The recent and rather contentious discussion is not taking place because FreeBSD developers feel that, philosophically, longer support timelines for releases are undesirable. Rather, the argument being made is that, given the underlying assumption of finite resources already committed to particular ends, we should moderate the degree to which we support old releases so that we can keep producing new ones. Don't think that the same trade-offs and hard choices don't have to be made in the development HEAD: in the past, we've pushed back several major features over time due to concerns about stability or availability of developers, which have been far more contentious. Just a thought... :-) 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: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
On Mon, Jun 09, 2008 at 06:55:06AM +1000, Peter Jeremy wrote: On 2008-Jun-08 17:49:20 +0200, Michel Talon [EMAIL PROTECTED] wrote: and it is now working perfectly well without any trouble. The only gotcha is the slowness of X problem when compiling, but i live with that. Have you tried SCHED_ULE? In my experience, it does a better job of scdeduling than SCHED_4BSD, even on UP machines (YMMV). Yes, i run with SCHED_ULE, the machine is less interactive than with 6.2 when compiling, but, as i said, i don't care much about that. What i really don't like is panicking, and with 7.0 my machine is perfectly stable. On the other hand, many tasks run very fast under 7.0, so, overall i am very happy with this version. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
On Sun, Jun 8, 2008 at 4:49 AM, Andy Kosela [EMAIL PROTECTED] wrote: On 6/8/08, Freddie Cash fjwcash at gmail.com wrote: On 6/7/08, Jo Rhett jrhett at netconsonance.com wrote: The question I raised is simply: given the number of bugs opened and fixed since 6.3-RELEASE shipped, why is 6.3 the only supported version? Why does it make sense for FreeBSD to stop supporting a stable version and force people to choose between two different unstable versions? Is this really the right thing to do? Define the terms stable and unstable, how you measure said stability and instability, and what you are comparing them against. This whole discussion is really interesting as it clearly showcases two common trends in computing (rapid development vs stability) Like I said, you have to define what you mean by stable and unstable before the discussion can continue. stable can mean many things to many people. You talk about feature stability. Other may talk about number of open bugs as being unstable. Others may talk of API/ABI stability. Other may mean code that don't crash a system. Your view of stable meaning features don't change is no where near my definition of stable (systems that don't crash, and where I can run binaries from older point releases on newer point releases). The joy of English is that words are overloaded with multiple meanings. And until everyone agrees on which meaning of the words they are using, there's very little point in discussing things ... as everyone will be talking about something different. -- 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: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
On Sun, 8 Jun 2008, Freddie Cash wrote: Define the terms stable and unstable, how you measure said stability and instability, and what you are comparing them against. This whole discussion is really interesting as it clearly showcases two common trends in computing (rapid development vs stability) Like I said, you have to define what you mean by stable and unstable before the discussion can continue. stable can mean many things to many people. You talk about feature stability. Other may talk about number of open bugs as being unstable. Others may talk of API/ABI stability. Other may mean code that don't crash a system. Your view of stable meaning features don't change is no where near my definition of stable (systems that don't crash, and where I can run binaries from older point releases on newer point releases). I think very few companies that use FreeBSD want it to be like OpenVMS -- otherwise they'd be using OpenVMS. Companies, and users generally, come to FreeBSD not just because they want system stability over time, but also because they expect us to keep producing new (yet mature) features. Sure, they may claim otherwise, but in practice they discover they do want FreeBSD to support the latest rev of an ethernet chipset on a motherboard because the replacement parts they received from their hardware vendor have it, support for larger disk sizes, support for a new POSIX API, being able to boot on systems that require (rather than just support) ACPI, etc. And those changes, perhaps individually incremental, add up to significant changes requiring new releases quite quickly. Again, I wouldn't argue that we couldn't further improve things, but at the same time, we have to recognize that any discussion about improvement in a world of finite resources requires a change in the set of trade-offs we accept. This is one reason why such discussions get contention, because one person's easy win from a change becomes another person's loss. 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: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
(Top posted because I didn't want to snip what you said) Bruce, all of what you said below is well known. I understand and don't have any problem with this. You seem to be trying to address something I wasn't asking about -- certifications, etc and such. Not a concern. The question I raised is simply: given the number of bugs opened and fixed since 6.3-RELEASE shipped, why is 6.3 the only supported version? Why does it make sense for FreeBSD to stop supporting a stable version and force people to choose between two different unstable versions? Is this really the right thing to do? On Jun 5, 2008, at 5:03 AM, Bruce M. Simpson wrote: It is worth remembering that FreeBSD is an open source project, and it's maintained on a best-effort basis -- it is offered for free and without any warranty. Like any other open source project, risk management and change management becomes a two-way street, because that's the trade-off struck with the open source model. The risks, as well as the benefits, have to be factored in carefully to your company's technology strategy, as I'm sure you're aware. I'm very surprised that the 6.3 train has been a big issue for you, although speaking from the development side of the fence, there are a lot of moving targets, and vendor support of the OS does play a part. It is difficult to offer any more specific advice without knowing in more detail exactly what's causing such problems for you, although I see you've offered general pointers, the folk directly involved need to be pointed at direct information. The FreeBSD Project just doesn't have the resources to do compatibility testing on the scale of e.g. Windows Hardware Quality Labs, as I'm sure you are also aware. I take on board what you say about your organisation holding back on an upgrade because there are PRs filed for the hardware you use, and having worked in an investment banking environment, I understand this level of conservatism is warranted. However, I point out again: it's the open source model, and where hardware compatibility is concerned, it really is a case of suck it and see. Always has been, no different anywhere else. Open source requires user participation. Microsoft run the WHQL because their status as a going concern depends on it. I'm pleased to hear about your offer of hardware resources for developers. However, this is only part of the problem. To my mind, you need to find the right people, with the right skills, to deal with the issues, and quite often, those guys are already in demand, and thus their time can attract a high value. Open source succeeds because money is not the only motivation. The alternative is DIY, and that is the point. If you need firm guarantees about support, consider contracting with someone to do that. Many companies using FreeBSD already outsource this kind of support requirement to 3rd parties. There are also FreeBSD hardware vendors who support FreeBSD as a platform. If you want someone to take responsibility, make 'em an offer. thanks, BMS -- 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: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
On Jun 5, 2008, at 5:51 AM, Jeremy Chadwick wrote: If the exact regression between 6.2 and 6.3 can be tracked down, great. If it's in a specific driver, CVS commit logs or cvsweb will come in handy. Otherwise, if it's some larger piece of code (ohai i revamped the intrupt handlar!), chances of finding it are slimmer. I'm a bit disappointed that Jo hasn't explicitly mentioned what's broken in 6.3 that's affecting him, because that might help everyone. Heck, I'll even add it to my Commonly reported issue wiki page. PRs would be good, but I'll gladly take past mailing list discussions. I will start a new thread with the specific issues that concern my environment upon my return. I'd like to keep the specific issues separate from the overall policy question, because they are very different in my mind. Jo's opinion is reasonable, but the bottom line is that the FreeBSD Project folks will always win the argument once the it's best-effort trump card is played; the convo has to end once it's on the table. Yes, but it often gets played too often too fast. It's worth having a discussion of the policy goals. I'm not saying that this isn't the very best that FreeBSD can do -- maybe it is. I just couldn't find any documentation of why dropping 6.2 makes a lot of sense, so I was hoping to get a clear answer for that. -- 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: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
On Sat, 7 Jun 2008 12:53:10 -0700 Jo Rhett [EMAIL PROTECTED] wrote: Why does it make sense for FreeBSD to stop supporting a stable version and force people to choose between two different unstable versions? Is this really the right thing to do? NO, it's not. But you can't change that. The maintainers run the show. It's their time and their baby. And from one pov that's true. Users have to shut up if not contributing big time. I still think your questions are legitimate. You won't win the battle however. -- Dick Hoogendijk -- PGP/GnuPG key: 01D2433D ++ http://nagual.nl/ + SunOS sxde 01/08 ++ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
On Jun 7, 2008, at 12:59 PM, Dick Hoogendijk wrote: I still think your questions are legitimate. You won't win the battle however. Obviously I got a battle, but that wasn't what I wanted. I wanted to understand the issues involved and from that determine how I might be able to help. -- 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: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
On Sat, Jun 07, 2008 at 12:53:10PM -0700, Jo Rhett wrote: ... The question I raised is simply: given the number of bugs opened and fixed since 6.3-RELEASE shipped, why is 6.3 the only supported version? Why does it make sense for FreeBSD to stop supporting a stable version and force people to choose between two different unstable versions? Is this really the right thing to do? In what sense do you consider 6.2 stable? Stable as compared to what? I think a part of the problem here - not the only part - is that you are using idiosyncratic definitions of terms. -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] / [EMAIL PROTECTED] President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
Jo Rhett wrote: I am suggesting that given that the current bug list for 6.3-RELEASE is both (a) too large and (b) breaks things that work fine in 6.2 ... that I think pushing 6.2 (the real stable release) into EoL is a bit rushed. I sympathize with the development costs of maintaining old versions. Again, I will help in any way I can. I'm sorry to hear about the problems you've been having. It is worth remembering that FreeBSD is an open source project, and it's maintained on a best-effort basis -- it is offered for free and without any warranty. Like any other open source project, risk management and change management becomes a two-way street, because that's the trade-off struck with the open source model. The risks, as well as the benefits, have to be factored in carefully to your company's technology strategy, as I'm sure you're aware. I'm very surprised that the 6.3 train has been a big issue for you, although speaking from the development side of the fence, there are a lot of moving targets, and vendor support of the OS does play a part. It is difficult to offer any more specific advice without knowing in more detail exactly what's causing such problems for you, although I see you've offered general pointers, the folk directly involved need to be pointed at direct information. The FreeBSD Project just doesn't have the resources to do compatibility testing on the scale of e.g. Windows Hardware Quality Labs, as I'm sure you are also aware. I take on board what you say about your organisation holding back on an upgrade because there are PRs filed for the hardware you use, and having worked in an investment banking environment, I understand this level of conservatism is warranted. However, I point out again: it's the open source model, and where hardware compatibility is concerned, it really is a case of suck it and see. Always has been, no different anywhere else. Open source requires user participation. Microsoft run the WHQL because their status as a going concern depends on it. I'm pleased to hear about your offer of hardware resources for developers. However, this is only part of the problem. To my mind, you need to find the right people, with the right skills, to deal with the issues, and quite often, those guys are already in demand, and thus their time can attract a high value. Open source succeeds because money is not the only motivation. The alternative is DIY, and that is the point. If you need firm guarantees about support, consider contracting with someone to do that. Many companies using FreeBSD already outsource this kind of support requirement to 3rd parties. There are also FreeBSD hardware vendors who support FreeBSD as a platform. If you want someone to take responsibility, make 'em an offer. thanks, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
On Thu, Jun 05, 2008 at 01:03:04PM +0100, Bruce M. Simpson wrote: Jo Rhett wrote: I am suggesting that given that the current bug list for 6.3-RELEASE is both (a) too large and (b) breaks things that work fine in 6.2 ... that I think pushing 6.2 (the real stable release) into EoL is a bit rushed. I sympathize with the development costs of maintaining old versions. Again, I will help in any way I can. I'm sorry to hear about the problems you've been having. If the exact regression between 6.2 and 6.3 can be tracked down, great. If it's in a specific driver, CVS commit logs or cvsweb will come in handy. Otherwise, if it's some larger piece of code (ohai i revamped the intrupt handlar!), chances of finding it are slimmer. I'm a bit disappointed that Jo hasn't explicitly mentioned what's broken in 6.3 that's affecting him, because that might help everyone. Heck, I'll even add it to my Commonly reported issue wiki page. PRs would be good, but I'll gladly take past mailing list discussions. Jo's opinion is reasonable, but the bottom line is that the FreeBSD Project folks will always win the argument once the it's best-effort trump card is played; the convo has to end once it's on the table. I consider myself an advocate of open-source, but simultaneously, was raised as a child to take responsibility for things I bring unto others. I do not publicly release code/binaries for things I do not wish to provide support for. Likewise, bugs in my software are my fault, thus thus my responsibility to fix. The FreeBSD Project does things differently than how I do. I have a hard time understanding the opposing view, but every time it comes up, I try a little harder to be open-minded about it. Jo, as we share somewhat of the same viewpoint, I'll mention that it would be within our best interest to try and understand the other viewpoint, and hope that the results of (positive) karma are seen down the road someday. If you want someone to take responsibility, make 'em an offer. In my case, with some FreeBSD bugs in the past, I have offered monetary compensation (hourly wages, reasonable by Bay Area standards) to developers to fix issues -- only to receive absolutely no response. Offering monetary compensation is not a solution, and I believe that's because the core problem isn't lack of pay -- it's lack of time. That's one which is really hard to solve, no matter what the conditions of an open-source project. On the other hand, there was the donation thing phk@ did when he was out of work, which I felt was great. I still feel good about donating to that. -- | 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: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
Hi, all, On Thu, Jun 05, 2008 at 05:51:05AM -0700, Jeremy Chadwick wrote: On Thu, Jun 05, 2008 at 01:03:04PM +0100, Bruce M. Simpson wrote: Jo Rhett wrote: I am suggesting that given that the current bug list for 6.3-RELEASE is both (a) too large and (b) breaks things that work fine in 6.2 ... that I think pushing 6.2 (the real stable release) into EoL is a bit rushed. I sympathize with the development costs of maintaining old versions. Again, I will help in any way I can. I'm sorry to hear about the problems you've been having. If the exact regression between 6.2 and 6.3 can be tracked down, great. If it's in a specific driver, CVS commit logs or cvsweb will come in handy. Otherwise, if it's some larger piece of code (ohai i revamped the intrupt handlar!), chances of finding it are slimmer. I'm a bit disappointed that Jo hasn't explicitly mentioned what's broken in 6.3 that's affecting him, because that might help everyone. Heck, I'll even add it to my Commonly reported issue wiki page. PRs would be good, but I'll gladly take past mailing list discussions. Since we, too, use quite a few machines in production, most of them 6.3 BTW, i spent some time searching the PRs with the keyword 3ware and varying combinations of release, severity, etc. I was not able to find anything with respect to that hardware that wasn't recorded as early as 6.1. em0 lockups were fixed around 6.1 for us with Jack Vogels kind assistance (and hardware provided by us ;-) Kind regards, Patrick M. Hausen Leiter Netzwerke und Sicherheit -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 [EMAIL PROTECTED] http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
On Thu, 05 Jun 2008 05:51:05 -0700 Jeremy Chadwick [EMAIL PROTECTED] wrote: Offering monetary compensation is not a solution, and I believe that's because the core problem isn't lack of pay -- it's lack of time. That's one which is really hard to solve, no matter what the conditions of an open-source project. Hmm, perhaps you and others should train people instead? Offer to pay a student to learn FreeBSD, and to train her / him as developer. I don't know if it is at all possible to fund something like that within the econimcs of a company such as yours, but if it worked, it would bring more developers on board. Just an idea. -- Regards, Torfinn Ingolfsen, Norway ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
Torfinn Ingolfsen wrote: On Thu, 05 Jun 2008 05:51:05 -0700 Jeremy Chadwick [EMAIL PROTECTED] wrote: Offering monetary compensation is not a solution, and I believe that's because the core problem isn't lack of pay -- it's lack of time. That's one which is really hard to solve, no matter what the conditions of an open-source project. Hmm, perhaps you and others should train people instead? Offer to pay a student to learn FreeBSD, and to train her / him as developer. http://www.freebsd.org/projects/summerofcode-2008.html -- 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: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
On Thu, 05 Jun 2008 10:01:40 -0700 Doug Barton [EMAIL PROTECTED] wrote: Torfinn Ingolfsen wrote: On Thu, 05 Jun 2008 05:51:05 -0700 Jeremy Chadwick [EMAIL PROTECTED] wrote: Offering monetary compensation is not a solution, and I believe that's because the core problem isn't lack of pay -- it's lack of time. That's one which is really hard to solve, no matter what the conditions of an open-source project. Hmm, perhaps you and others should train people instead? Offer to pay a student to learn FreeBSD, and to train her / him as developer. http://www.freebsd.org/projects/summerofcode-2008.html Yes, I know about Google SoC, and it is a good thing (a _very_ good thing). I was thinking more along the lines that if offering money for fixing stuff doesn't work, then maybe getting more interest (in addition to SoC) would work better. Therer must be a reason why nobody has formed a commercial compnay to fix bugs / develop new features fro FreeBSD (either with own employees or with hired people) already. To me, that means that the demand isn't big enough to make it a viable business plan. -- Regards, Torfinn Ingolfsen, Norway ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
