From owner-freebsd-current Wed Jun 21 2:40:34 2000 Delivered-To: freebsd-current@freebsd.org Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by hub.freebsd.org (Postfix) with ESMTP id E3C9037C20E for ; Wed, 21 Jun 2000 02:40:27 -0700 (PDT) (envelope-from n_hibma@qubesoft.com) Received: from calcaphon.demon.co.uk ([193.237.19.5] helo=bluebottle.qubesoft.com) by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1) id 134gze-000CZy-0W; Wed, 21 Jun 2000 10:40:23 +0100 Received: from henny.webweaving.org (henny.qubesoft.com [192.168.1.5]) by bluebottle.qubesoft.com (8.9.3/8.9.1) with ESMTP id KAA43149; Wed, 21 Jun 2000 10:40:58 +0100 (BST) (envelope-from n_hibma@qubesoft.com) Received: from localhost (localhost [127.0.0.1]) by henny.webweaving.org (8.9.3/8.9.3) with ESMTP id XAA34135; Tue, 20 Jun 2000 23:51:17 +0100 (BST) (envelope-from n_hibma@qubesoft.com) Date: Tue, 20 Jun 2000 23:51:17 +0100 (BST) From: Nick Hibma X-Sender: n_hibma@localhost Reply-To: Nick Hibma To: Warner Losh Cc: Matthew Dillon , Jason Evans , current@FreeBSD.org Subject: Re: HEADS UP: Destabilization due to SMP development In-Reply-To: <200006201927.NAA71421@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG CAM is not a valid example. It only touched the disk subsystem. Merging back changes in blocks might not be possible. As Matthew mentioned, Chuck's experience should be taken for a fact. And bounding the amount of breakage is almost impossible without squeezing the people doing the SMP work really badly. I don't think that that is reasonable. Nick > One could argue that you could merge the changes to FreeBSD 5.X on a > daily or weekly basis to that branch so that the branch doesn't get > too far out of what. Perforce users do this all the time (cf the cam > project). The model that I see is that a branch is created for SMP > work, and that you find a volunteer who has access to SMP machines who > will merge from current into the SMP branch once a week and boot the > resulting kernel. If it works, he commits it, otherwise he resovles > the problems. That way the main developers aren't significantly > impacted by the merging. > > I'd be a lot happier if there was an upper bound on the length of time > that -current would be unstable, if there was a plan in place on what > to do if that timelimit was exceeded, if there was a roadmap I could > look at, etc. Right now the vagueness of it all pushes my panic > button. I'm trying to get more information so that I know if I should > just calm down and it won't be that bad, or if I should pitch a huge > fit because it will be too painful to make progress on any other > front. Please help me with that. > > I'd also be happy if I could create a newcard branch off the last > stable version of freebsd 5.0-current. That way I could continue my > work with others and the instability wouldn't matter. All merging, if > any, would be my responsibility. I don't know what the level of pain > > Of course the same arugment about merging you make could be made for > new kernel work. They will either have to live with the pain (which > is currently ill-defined at best, knowing what the pain would be would > help my confort level), or do their work and then redo it on the new > and improved FreeBSD months later. Why should SMP force others to do > that? > > Warner > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > -- n_hibma@webweaving.org n_hibma@freebsd.org USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message