From owner-freebsd-hackers Thu Jun 3 23:47: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (Postfix) with SMTP id 0E7891543C for ; Thu, 3 Jun 1999 23:47:06 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (qmail 28617 invoked from network); 4 Jun 1999 06:47:02 -0000 Received: from dyson.iquest.net (198.70.144.127) by iquest3.iquest.net with SMTP; 4 Jun 1999 06:47:02 -0000 Received: (from root@localhost) by dyson.iquest.net (8.9.1/8.9.1) id BAA05658; Fri, 4 Jun 1999 01:46:49 -0500 (EST) From: "John S. Dyson" Message-Id: <199906040646.BAA05658@dyson.iquest.net> Subject: Re: 3.2-stable, panic #12 In-Reply-To: <199906040636.XAA27939@implode.root.com> from David Greenman at "Jun 3, 99 11:36:00 pm" To: dg@root.com Date: Fri, 4 Jun 1999 01:46:49 -0500 (EST) Cc: wes@softweyr.com, dyson@iquest.net, dillon@apollo.backplane.com, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> IMO, revokation of commit privs has given enough time to support > >> the learning curve and enforce a review process. > > > >I've been following this conversation with growing concern. It seems > >to me there is a fairly simple solution to this problem: create a > >branch for the ongoing VM work, enable commit privs on the branch for > >Matt and anyone else who's going to join in the fun, and then at times > >when they think it is appropriate and things have been adequately > >reviewed, we have a little merge-mania and things are better than ever. > > > >Are there any technological boundaries that prevent us from doing this? > >This is how we do it in the paid-for-code world. ;^) > > It sounds good at first, but sounds less so when you actually have to merge > the branches - this can be very difficult to do when lots of time has gone > by, especially when various (software) interface/infrustructure changes have > been made to both branches. They only way it would work would be if the time > differential were kept very short (perhaps one month or less). > It would be good to somehow come up with a creative scheme that would statisfy Matts patience issues and get the code out so that it can be tested and used before committing the code to the "real" tree. I do understand Matt's issues regarding waiting for people to review code, but things would also work better if changes are "reviewed" before they are coded. John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message