Re: so what is involved in calling squid-3.0 'stable'?

I guess the short answer to the subject is 'a lot of time from the
core team' :(.

> >>> <..snip..>
> >>> So, what is required. How can we engage the community in making squid-3
> >>> stable ? There seems to be non-trivial interest in making it happen, but
> >>> whats the actual benchmark ?

This reminds me the apache's 1.3 -> 2.X transition: apache 2 is much
more flexible and powerfull, but a lot of people still preffer 1.3.
Mainly because apache 2.X does not add any signifficant feature from
the sysadmin/apache user perception, and only a small fraction of
apache users' actually need those new architecture features.

I guess something similar is happening with squid3: current squid2
users do not realize about the good new features of squid3 (client
streams => [icap, content compression], external_acl with it's
negative_ttl, acl based tcp_outgoing_address, and so on), or perhaps
they just don't need them.

> >> I'll start using it again and pushing forward with bug reports if there's
> >> someone there to work on them...last time I tried squid-3 I was seeing some odd

While it's easy to say 'someone has to fix the bugs I find', I guess
that's the squid3-users feeling. If a sysadmin is going to spend time
testing squid3, he/she expects to have some feedback on the issues
he/she finds. The same happends for newcomers to the squid3-dev
community: as squid3 is extremely complex, they expect some 'tutor' to
guide them; which again falls back to 'squid core team time' :(.

I've been using squid3 in my production proxys for about 2 years, and
it's been working great. I've allways commited every single bug I've
came across to bugzilla, and posted a patch every time I could write
one. Of course, I do not have enough knowledge of squid internals to
commit the patches by my self, so, basically 'someone has to review &
commit the patches I write' :D.

Fixing bugs for squid3 is not easy at all due to:
1) naming conventions (I agree with Nick Lewycky at some level).
2) missing documentation: doxygen is my best friend on understanding
squid3 architecture. But sometimes is not enough :(, and reading
hundreds of lines of code across tens of files is the only way I find
and it takes a lot of time due to missing documentation.
3) abuse of some fancy C++ features complicates the whole matter, and
sometimes they only make squid3 compile time even longer (over 40
minutes in an old CPU).

> > There are definately people doing things around the source - I think
> > harnessing the energy is the issue. I only have a small amount of time,
> > and I'll probably be using it on toolchain support to make it easier for
> > others to fix bugs - because thats something effective I can do in the
> > timeframes I have available.
>
> That's cool.
>
> Changing the subject a little, there have been many new people introduce
> themselves on this list maybe with good intentions of working on squid, who seem
> to vanish as fast as they arrive. I wonder if they've simply (a) never intended
> to contribute in the first place, (b) done some work privately but never
> released it or (c) taken a good look at the code, and run away fast deciding it
> was all too hard ;-)

Squid3 has a stair-shaped learning curve, so I believe it's (c).

> From a development perspective, I think it'd be of value to know why are there
> not more people developing squid. It seems to be just a "hardcore" few.........

Developers will come if squid3 is promoted, say by enumerating it's
features in www.squid-cache.org.

Hope this helps,

--
Gonzalo A. Arana