Re: update on 1.2

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

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

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.
        
I just started to work on Squid full time so my opinion is not important, but
I believe that we need _more_ coordination of what is being updated/patched,
especially during major changes (e.g., 1.2). I am currently looking at a
_stream_ of great patches that we will have to re-code because they update
the code that is no longer there or has changed quite a bit. Suffice to say,
that we sometimes have update conflicts even among three of us at nlanr... :)

Again, I have very limited experience with coordination of distributed
projects, and the benefits of more coordination might be outweighed by
wonderful "surprise" patches that we sometimes get now.

$0.02,

Alex.

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