Date: Fri, 04 Jun 1999 01:31:32 -0600 From: Wes Peters <wes@softweyr.com> To: dg@root.com Cc: dyson@iquest.net, dillon@apollo.backplane.com, freebsd-hackers@FreeBSD.ORG Subject: Re: 3.2-stable, panic #12 Message-ID: <375780D4.1A3D1664@softweyr.com> References: <199906040636.XAA27939@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?375780D4.1A3D1664>