Date: Mon, 6 Dec 1999 14:43:31 -0600 From: Karl Denninger <karl@Denninger.Net> To: Matthew Dillon <dillon@apollo.backplane.com>, Dennis <dennis@etinc.com> Cc: hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) Message-ID: <19991206144330.B25513@Denninger.Net> In-Reply-To: <199912062019.MAA72301@apollo.backplane.com>; from Matthew Dillon on Mon, Dec 06, 1999 at 12:19:20PM -0800 References: <19991205120428.E6F4514C3E@hub.freebsd.org> <199912061939.OAA22030@etinc.com> <199912062019.MAA72301@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 06, 1999 at 12:19:20PM -0800, Matthew Dillon wrote: > :>:the problem, we can not address it. please provide this information > :>:if it is available to you. if it is not, please provide us contact > :>:information for the commercial entities experiencing the problem. > :>: > :>:jmb > :> > :> First, the statement was anecdotal -- all of the problems have been > :> fixed in -current. > : > :THIS is EXACTLY what I was saying. What good does it do anyone in a > :commercial environment that its fixed in -current? Thats the reason we > :dumped NetBSD, because everyone was using -current the the releases were > :always unstable. > : > :Of course moving to -current to fix the problems in 3.x introduce a whole > :new set of problems, in which case you have an OS that is never going to be > :stable. When 4.0 is released we'll be told that the problems of 4.0 are > :fixed in -current. When does it end? > : > :DB > > I think the solution here is to change the release mechanism slightly. > I believe we made a huge mistake splitting of the 4.x tree from 3.x > so early. > > This time around I think that we should *not* split the tree for > four months or so. That is, have a period of 4 months where there is > only 4.x, no 5.x. Well, I used to run -CURRENT in a commercial environment :-) And I got bashed here and elsewhere for doing it too. But, with the exception of some really egregious fuck-ups (on both my part and those of people who committed shit that didn't work AT ALL) it was, by far, the better option of those available. For quite some time there were special "hacks" that I had (primarily consisting of grabbing older versions of this module or that) to get around stupidities that were in the process of being resolved, and there were always things that I disabled or just didn't do because I knew they were broken. But, by and large, this was a very solid and appropriate path FOR ME. It *DOES* require TWO machines for testing purposes - one of which has the code base on it, and a second that can be "sacrificed" and reloaded if you really get your shorts in a knot. You also need to keep a known-good release around "just in case" you need to roll back after you commit a roll-forward. But, for me at least, I was happy with this path, despite the few instances over the years where I got bit in the ass by it. I truly believe I would have had MORE chunks out of my ass trying to run STABLE in the same world. And, today, I STILL live by that credo. My primary home machine, which is a production system in every sense of the word, runs CURRENT, although at this point the kernel is a few months old (I've had no reason to upgrade it recently, although I do peruse the "sys" commitlogs at least weekly). :-) -- -- Karl Denninger (karl@denninger.net) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991206144330.B25513>