Re: 3.2 release checkup

On 02/27/2011 07:35 PM, Amos Jeffries wrote:
> The long-term plan I have was hoping to release 3.2 stable next weekend
> (yeah right!).
>
> These are the issues I know if still holding us at step 3 (beta) on the
> release checklist:
> (http://wiki.squid-cache.org/ReleaseProcess)
>
> * auth crashes in Negotiate and NTLM - Amos.
>
> * IPv6 split-stack incomplete (multiple OS require this) - Amos.
>
> * StringNG upgrade merged - Kinkie, Alex ?
>
> * SMP cache/store support (RockStore) - Alex
>
> * 8 bugs major or higher outstanding from 3.0 stable
>
> * 26 bugs major or higher outstanding from 3.1 stable
> (several will be resolved by the above work)
>
>
> Could I get an estimate of how much longer these are likely to take please?
>
> Also, if there are other issues you see not mentioned, please let me
> know or ensure the bug about it is marked an appropriate level of severity.

The biggest 3.2-related items on my plate are:

* SMP Rock Store: working now, but missing one major performance
optimization (shared RAM cache) and integration polishing. I have
already posted some related Store changes (reviewed by Amos, thank
you!). The 3p2-rock branch on Launchpad contains current code. I hope to
post more patches and start merging stuff in three weeks.

I think Rock Store changes should be committed before the stable v3.2
release (to make it attractive enough compared to v3.1 and v2.7), but I
cannot insist on that.

* eCAP v0.2.0 support: Patch posted a week ago (see the "Support libecap
v0.2.0" thread). Will commit this week unless there are reviews
requiring many changes or objections.

Updating eCAP support can be viewed as a v3.2 release blocker, IMO,
because we are behind on supporting several key official eCAP features
needed by most production eCAP adapters (as well as any checks that
installed libecap is compatible with what Squid supports). It will also
help with making v3.2 significantly more attractive than v3.1 unless
somebody ports the needed changes back to v3.1.

* Squid3 performance regressions: As discussed on several recent threads
we need (a) identify the remaining regression points and (b) fix some of
them to bring performance back on par with v3.1 (at least). I already
posted a few regression points for (a) and hope to complete that list
within a few weeks.

This work is a v3.2 release blocker, IMO, because we should not deliver
a new stable release that is significantly "slower" than the previous
one. While some of the items like IPv6 may take a long time to optimize,
I hope there are enough easier targets that we can fix in a matter of
weeks rather than months. Overall, however, this will take time unless
more people pitch in.

* StringNG: Last time I checked the public branch, there were still many
previously identified problems that were not fixed. I am guessing that
Kinkie is sick and tired of these iterations and do not expect him to
work on that branch beyond its current state until I produce a patch
with specific fixes (like we did with the MemBlob code).

I do not plan working on StringNG until the above three items are
closed. Meanwhile, I hope Kinkie will add memory pooling for committed
MemBlob code. Without it, we probably should not use new strings in core
code anyway.

From user point of view, I do not think StringNG work is a v3.2 blocker.
From developer point of view, it would be nice to finally get it
committed and start using it, of course.

Thank you,

Alex.

> Additional important issues with less urgency:
>
> * Windows support - Amos, Kinkie, Guido ?
>
> * stale-while-revalidate
> ** requires async revalidation, which is blocked by store changes
>
>
> Amos
Received on Mon Feb 28 2011 - 22:33:44 MST