Importing recent trunk changes to 3.1

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Sun, 12 Jul 2009 19:51:25 -0600

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.

Overall, there are too many conflicting informal factors so any decision
can be rationalized. I guess we should just vote whether these changes
should be imported into v3.1.

Thank you,

Alex.
Received on Mon Jul 13 2009 - 01:51:36 MDT

This archive was generated by hypermail 2.2.0 : Mon Jul 13 2009 - 12:00:04 MDT