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
