[squid-dev] [RFC] The final phase of 3.5 testing/

[Amos Jeffries]

On 19/09/17 12:45, Eliezer Croitoru wrote:
> Hey All,
> 
> In the last 2 year I have tested Squid-Cache 3.5 and for general purposes
> and it's stable.
> The basic challenge is a simple internal traffic but there are couple other
> challenges which I would like to verify.
> The first thing is a test of squid against a very hostile environment like
> the public Internet.
> By testing on the public Internet I mean that it will sit in intercept or
> trproxy mode ontop of a "VPN" service.
> I believe that such a test would benefit us with more details about the
> stability of the 3.5 branch and later maybe test the 4.x branch.
> There are some legal issues in running such a setup and I would not be able
> to run such a setup without some valid usage agreement.
> 
> First what do you all think about the idea in general?

We have various people actively using the latest code of both the v5 and 
v4 series. So Squid code of all branches is already being run in various 
production situations. Its just that since they are commercially 
sensitive we do not get feedback unless things actually go wrong.


> Second, would we be able to somehow list the known 3.5 bugs?

Each Squid series wiki page links to the bugzilla report listing all 
bugs which are still open and affecting that release.
eg <https://wiki.squid-cache.org/Squid-3.5#Open_Bugs>


> I believe that such a list will help the admins to decide if Squid-Cache is
> for them or not.
> Currently there are 574 open bugs on the Bugzilla and maybe some of these
> are not even relevant to 3.5.
> -
> http://bugs.squid-cache.org/buglist.cgi?bug_status=__open__&content=&limit=0
> &no_redirect=1&order=priority%2Cbug_severity&product=Squid&query_format=spec
> ific
> 
> Amos, You have suggested to walk me through some of the bugs to make our
> lives much easier.
> And I was thinking for example this bug: 3.2.1 SEGFAULT while freeing
> ipcache_entry
> http://bugs.squid-cache.org/show_bug.cgi?id=3644
> 
> It's a Solaris based squid which appeared in 3.2 and was confirmed by the
> reported as "works for me" but never been marked this way.
> If I'm not wrong Yuri also works or worked with solaris and can verify if
> this kind of a bug exists or not on 3.5 can then we can close it as "works
> for me".

More correctly it disappeared without anyone making changes. So may 
recur at any time.

There have been some major changes to the memory management and safety 
since that version, but not so much in terms of ipcache improvements 
except indirectly through libmem / MEMPROXY pool changes.

The uncertainty there means leaving it open until more certainty happens 
just in case it does recur.

> 
> 
> Also this bug: PURGE not purging hot objects (TCP_MEM_HIT ) with
> memory_cache_shared on
> http://bugs.squid-cache.org/show_bug.cgi?id=3888
> 
> Which I have seen that some work is being done on github  to resolve this
> bug(3888)
> It's there for at-least 3 years but nobody changed the milestone to what so
> version.
> I upped up the milestone to 3.5 since any patch will not be created by the
> squid project itself to older versions then 3.5 ie .3.4 and down.
> If you think that the milestone is 5 or 4 please change accordingly.

The milestone needs to be set to the oldest version where the bug is 
known to be *fixed*. So the report in the wiki page can accurately list; 
for example that this bug is still affecting Squid-4.

If we do not have a) a patch applied to the code master branch and 
working its way down to whatever old version, or b) a confirmation that 
the bug is gone in latest code; then the milestone should stay unset.

Eduards patch is expected to get to v4 but not older, so it will 
eventually be milestone of v4 not v3.5.

Amos