Date: Fri, 4 Jun 1999 09:18:13 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: "John S. Dyson" <toor@dyson.iquest.net> 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 Message-ID: <Pine.BSF.4.05.9906040909190.81993-100000@semuta.feral.com> In-Reply-To: <199906040646.BAA05658@dyson.iquest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > >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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9906040909190.81993-100000>