From owner-freebsd-hackers Fri Jun 4 9:21:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 72C8014D77 for ; Fri, 4 Jun 1999 09:21:15 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id JAA17312; Fri, 4 Jun 1999 09:20:47 -0700 Date: Fri, 4 Jun 1999 09:18:13 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: "John S. Dyson" Cc: dg@root.com, wes@softweyr.com, dyson@iquest.net, dillon@apollo.backplane.com, freebsd-hackers@FreeBSD.ORG Subject: Re: 3.2-stable, panic #12 In-Reply-To: <199906040646.BAA05658@dyson.iquest.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > >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. I agree- to a point. Having been involved in a large number of different engineering "process" efforts at many companies, I can sympathize with all aspects to this problem. It's more difficult with FreeBSD because there's a notion of joint ownership for all who contribute. I would suggest that, all in all, a more active 'core' group that directs overall strategies and directs branches for major commits, might be the best mix here- along with folks actually doing real metrics to prove or disprove their assertions about the effects of VM and buffer cache things. All of this with a bit of looseness that has occurred up until now (not having things wired down has been a good thing, on balance). In terms of design reviews and architecture *before* the commit, well, if you want to go that route I can assure you it's a major amount of work. It will bring FreeBSD into "adult" development- no large scale project with > 50 engineers really succeeds long term without it, but are you really wanting to the tbings of: MRD (Market Requirement Document), External Reference Spec, Internal Reference Spec, Test Plan, Architecture Review, Implementation Review, *Commit*, Test, Release, Post Mortem Review..... -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message