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
