From owner-freebsd-hackers Fri Jun 4 0:31:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from obie.softweyr.com (unknown [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id D858014E42 for ; Fri, 4 Jun 1999 00:31:44 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com (homer.softweyr.com [204.68.178.39]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id BAA22851; Fri, 4 Jun 1999 01:31:33 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <375780D4.1A3D1664@softweyr.com> Date: Fri, 04 Jun 1999 01:31:32 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: dg@root.com Cc: dyson@iquest.net, dillon@apollo.backplane.com, freebsd-hackers@FreeBSD.ORG Subject: Re: 3.2-stable, panic #12 References: <199906040636.XAA27939@implode.root.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Greenman wrote: > > >> 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). I was thinking of shorter time frames than that. We often have branches that live just long enough to implement a single feature, sometimes only a few days. It helps that we use Perforce, which has a very fast lightweight branching mechanism, but the same strategy has been used with CVS on past projects. The idea here is to create a branch for an individual feature, turn on commits to that branch for generally anyone who wants to participate, and the have the branch available for review before merging it into the main development line. One of the requirements before the final merge is that the branch has been updated from the mainline and tested for 24 hours before the merge is OK'd. I know this seems like a lot of overhead, but it seems like SOME of the projects Matt is working on really need this flexbility, not because Matt is doing them but because they are gut-wrenching changes to the system and a mechanism needs to be created for several developers and (hopefully) numerous testers to share the work among each other in an environment where they're not continually breaking the system for other development work. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message