Re: [RFC] 3.4 release timetable

On 24/03/2013 5:35 p.m., Alex Rousskov wrote:
> On Sun, 24 Mar 2013, Amos Jeffries wrote:
>
>> We have 5 new features in 3.HEAD now and it seems to be stable enough
>> for public use.
>> See http://wiki.squid-cache.org/Squid-3.4 for the list of what I am
>> classifying as a new feature.
>>
>> *** I am contemplating branching 3.4 into a beta series in the coming
>> weeks ***
>>
>> That will mean probably June or July for a stable release.
>
>
> Hi Amos,
>
> Thank you for managing the release cycle.
>
>
>> Are there any objections?
>
> No objections from me, although I am concerned that, based on the wiki
> page you referenced, trunk may have no significant new features to
> warrant differentiating it from v3.3 now, except perhaps for Store ID.
> This may explain why the trunk is about as stable as v3.3 :-). On the
> other hand, if branching v3.4 now will not increase support and
> porting overheads (e.g., because we will stop supporting v3.2??), then
> we should "release early, release often", I guess.
>
>
> FWIW, there are several significant features that are nearly ready for
> Squid Project review. Roughly ordered from most important/ready to
> least, these features include:
>
> 1. Large Rock. The code works in lab tests and is nearly ready for
> submission. The primary delay is that I want to bundle it with the
> Store API polishing I promised, but that polishing does not affect
> admins and can wait if we are in a hurry.

No hurry. But as I said to Kinkie weeks back, now when we have no beta
portages to work around is the best window for polishing patches to go
in as stand-alone updates. So don't feel obliged to bundle polish with a
new feature. Whichever one is ready first can go forward to review.

>
> 2. Basic collapsed forwarding. The code works in non-SMP mode, but I
> need to finish SMP support before I can submit the patch for Squid
> Project review. This may take a few weeks.

As 2.7 feature parity this one is eligible for consideration as a
back-ports where other features are not.

If this feature in a state that would be happy submitting a non-SMP
version for 3.4 with SMP support coming later? There are quite a few
installations of 2.7 needing this feature that would be able to cope
with non-SMP for a bit longer in exchange for all the other 3.x
benefits. They will be forced to wait even longer without those other
3.x benefits as it is now.

>
> 3. Secure tunnels to cache peers. The code works in lab tests, but we
> need to remove duplication of forward.cc pieces before I can recommend
> it for Squid Project review.
>
> 4. Shared SSL sessions among SMP workers. This performance
> optimization is important to folks accelerating secure sites using SMP
> Squid. The code works in lab tests, but we need to remove some
> duplication of StoreMap pieces before I can recommend it for Squid
> Project review.
>
> 5. Support for quoted strings in ACLs and other squid.conf options.
> The code needs some minor polishing.

If that is something we can do in audit then please submit to audit
quickly. It sounds like it would round out the 3.4 ACL and helper
changes nicely.

> Again, I do not object to v3.4 branching before the above features are
> posted for review. If you want to see at least some of them in v3.4
> (and do not want to port them later) then waiting 4-6 weeks may help.

Thank you for the update on whats coming. I have Bearer auth, Windos
support, StringNG, more helper kv-pair support and more notes support
which are probably not going to make this release either.

I'm not going to wait on anything that has not even been submitted for
review. That would be repeating all the same problems that held up 3.2
for years. However, that said I am happy to wait on branching until the
end of April or until one more large feature completes the audit
process. Whichever comes first.

Amos
Received on Mon Mar 25 2013 - 05:02:36 MDT