> > >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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
