Re: 3.2 release checkup

On 01/03/11 11:33, Alex Rousskov wrote:
> 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.
>

Agreed.

>
> * 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.

Oops, sorry, I meant to review it already. I'll get on to that in a day
or so. Hopefully that can be closed off by this weekend.

>
> * 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.
>

IIRC the list so far were for things which will take some time and
testing to get right and optimized again.

One of the items to check should be the speed affect of all the new uses
of vector<> instead of the existing squid Vector<> which was apparently
faster.

>
> * 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.

I bumped it to priority in my earlier list since it may prove a fast(er)
track to some performance gains.

Okay, so it seems a 6-weeks or so still. :(

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.11
   Beta testers wanted for 3.2.0.5