Date: Tue, 20 Jun 2000 18:33:05 -0500 (CDT) From: Mike Meyer <mwm@mired.org> To: current@FreeBSD.ORG Subject: Re: HEADS UP: Destabilization due to SMP development Message-ID: <14671.65329.854265.115471@guru.mired.org> In-Reply-To: <200006201833.MAA70626@harmony.village.org> References: <20000619115330.D79318@blitz.canonware.com> <200006201833.MAA70626@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh writes: > In message <20000619115330.D79318@blitz.canonware.com> Jason Evans writes: > : Summary: -current will be destabilized for an extended period (on the order > : of months). A tag (not a branch) will be laid down before the initial > : checkin, and non-developers should either stick closely to that tag until > : the kernel stabilizes, or expect large doses of pain. This tag will be > : laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning > : beforehand. > Thanks for the fair warning. Now don't do it. Has core approved > this? I don't think so, I've seen nothign from them about it. > > The instability ni -current for MONTHS is pain not acceptible. We've > never really allowed that in the past. A CVS branch would be mcuh > better for this sort of thing. I know that's a pain as well, but this > is just for SMP people and the rest of us shouldn't have to deal with > the pain. As someone who does consulting on for release engineering and such things, I'll comment that that's one of the key uses of branches; buliding a development branch so that adding major new features doesn't disrupt other development until they are as stable as the rest of the project. If CVS makes merging a branch back in a pain, and there isn't an open source tool (bitkeeper, maybe?) that solves this problem, then possibly a compromise can be reached with the folks at Perforce(*). They're reasonable people, and think highly of the FreeBSD project. "The Cathederal and the Bazaar" talks about transitioning from closed to open source, so I'd be very surprised if they haven't thought about these issues. As a for instance, possibly they could be talked out of sources for the client (client libraries, that is - the rest is trivial) and a spec for talking to the server, on the assumption that the truly valuable information is in the server. That way, the tools installed by developers would all be open source. Of course, Perforce may have no interest in this, but I can't think of anything more likely to convince them to make such a move than the possibility of the FreeBSD project moving to Perforce. > I understand your desire to have it all in a working tree, but causing > pain for ALL developers for potentially MONTHS isn't a reasonable > request. How far can the tag be stretched to make things work? Can CVS tags be changed to include updates versions of a file, so that there is some possibility that other developers could work with that tag, instead of creating another branch? <mike *) While I am a Perforce Consulting Partner, I have no official position with Perforce, I am *not* speaking for them, and I'm not privy to any of their strategic planning. If you want to know what the folks at Perforce think about any of this, ask them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14671.65329.854265.115471>