Re: update on 1.2

--MimeMultipartBoundary
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 20 Jan 1998, Alex Rousskov wrote:

> On Tue, 20 Jan 1998, Henrik Nordstrom wrote:
>
> > I agree on this. A shared CVS tree could help to speed up the development
> > cycle, especially when Duane has a lot of other things to attend to.
> > Does anybody know how others maintain shared CVS trees? What to look out
> > for and similar?
>
> I have heard a bit about Apache approach:
>
> - There is a shared Web-based CVS tree
> - One can "cvs checkout" anything and at any time, of course
> - Everybody can submit a piece of code to the -dev e-list
> - there is a "core" team of about 11 people who vote on every patch
> by responding to the list (comments might get wild :)
> - the patch circulates on the -dev list while they vote (this is a
> bit ugly)
> - the code is accepted and "cvs committed" when everybody(?) says "YES"
> - next official release comes with all committed patches

You don't want to follow the apache model! :) I've been arguing against
the voting system for a while. It appears in the past few weeks I've won
and we're moving to a more sane approach where we actually trust the folks
with cvs access... and voting just doesn't happen. The voting thing is a
huge time sink, and has almost made me not want to continue work on
apache. It slows down bug fixes rather than helping them. We still
discuss new features before coding though.

> One good thing about Apache code is that it has a nice modular structure
> designed to support distributed updates. Thus, besides small bug-fixes, new
> features are often added as optional cooperating(!) "plugin" modules and do
> not affect the core code. This is quite different from "100s of #ifdef
> MY_COOL_FEATURE" approach in Squid.

Yeah it's nice that we can do this. Occasionally we have to add a few
more hooks into the API though.

Dean

--MimeMultipartBoundary--
Received on Tue Jul 29 2003 - 13:15:45 MDT