Re: Importing recent trunk changes to 3.1

Lets kick the vote off now then....

On Sun, 12 Jul 2009 19:51:25 -0600, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> On 07/12/2009 06:28 PM, Amos Jeffries wrote:
>> I hate the size of this. I really do.
>
> I too wish it could be trickled into the trunk in smaller chunks over
> time, but I think we should still be grateful that these changes and the
> ICAP chaining code got implemented and released. The big-or-nothing
> choice is unfortunate, but the trickling overheads are significant and
> often exceed our very limited resources.
>
>> However there are several important 3.1 bugs that is either fixes, or
>> adds
>> support towards fixing easier.
>>
>> So, after 3.1.0.10 stabilization update is out I'll be considering the
>> 3p1
>> imports for 3.1.0.11.
>
> I think we should also consider importing the ICAP chains code. Here are
> the pros and cons I can think of:
>
> Cons:
> - Violating feature freeze policy sets a bad precedent.
> - There is a significant risk of hurting v3.1 stability.
>
> Pros:
> - The changes are often essential for NetCache parity.
> - Timing: folks are replacing end-of-life NetCaches _now_.
> - Any stability problems will be temporary.
> - Changes are easy to import (for now).
> - I will waste fewer cycles on 3p1-plus maintenance.
> - I may be able to spend more cycles on v3.1 code.
>
> Squid v3.2 timing is also a consideration, I guess. We do not have a lot
> of reliable statistics, but it may take another 10+ months before v3.2
> becomes stable. That version will have enough features to encourage
> upgrades even if adaptation chains are already supported in v3.1. On the
> other hand, v3.1 can benefit from a feature boost.

Your thinking parallels mine with a few extra Pros I had not thought of.

I'm voting +1 to adding both.

Amos
Received on Mon Jul 13 2009 - 02:53:18 MDT