Re: [squid-users] Squid-2, Squid-3, roadmap

>
> On 05/03/2008, at 1:39 PM, Amos Jeffries wrote:
>
>>> Well,
>>>
>>> I am interested in speed, features and ICAP.
>>> So I like -2 and -3 to merge.
>>>
>>> It seems to me that for the sake of being polite with each other
>>> we do not want to call the -2 / -3 issue a fork, but effectively
>>> it really is a fork.
>>>
>>> So here is my question back to the main maintainers:
>>> do you want to undo the fork and merge ?
>>> Note this: for a merge there are 2 ways:
>>> 1) port functionality from -3 to -2
>>> 2) port functionality from -2 to -3
>>
>> Don't forget the .5) tasks:
>> 1.5) port all changes made to -3 since starting the base port to -2.
>> 2.5) port all changes made to -2 since starting the base port to -3.
>>
>> (1) would require a full re-code of -2 into C++ (repeating 6+ years
>> of 3.x
>> development under a new name) in order to encompass the features of -3
>> that cannot be back-ported.
>
> Well, that's a bit of a straw-man, isn't it? AIUI 3 *is* already 2 re-
> coded into C++. Never mind the question of why that's necessary;
> indeed, I think a lot of people's discomfort is centred on the fact
> that large parts of 3 have been rewritten and not battle-tested in
> wide deployment.

Simply repeating the same changes, yes would be bad. But starting from
scratch can cause different experience-based design that may be better.
That is one of the crux problems being discussed by Core.

>
> I think you'd get that deployment if there were significant reasons
> for users to migrate; conversion to C++ is motivation for the
> developers, not the users, unless it's accompanied by user-visible
> improvements in performance, stability, or functionality. Again, while
> ESI and ICAP are cool and useful, IMO they don't motivate the majority
> of your users.

Personally I agree. The statement from Core shortly indicates the others
do too. We advocate that users pick -3 if they find -2 and -3 both match
their requirements. As you say, the motivation to choose between the two
is not large, and mostly centered around the fact that 5 out of 6 most
active developers are coding on -3.

>
>> (2) requires info from you the users, about what features you need
>> ported,
>> and some help on porting those over to -3.
>
> full vary/etag support
 - pending someone to work on it

> collapsed_forwarding
 - pending for 3.1 and someone to work on it

> stale-if-error
> stale-while-revalidate
 - Um, so why did you (the sponsor for these two I believe) not also
request their addition in -3 for future-proofing your install app?

> external_refresh_check
> pinned peer connections
 - thank you.

> external logfile daemon
 - pending for 3.1, I'm just about to start on this one myself.

> stablility
 - CODE stability: we are always working on this. Not much we can do
beyond; it doesn't crash, has no leaks, no reachable bad code paths, and
no memory access errors. As we find we fix.
 - DEVELOPMENT stability: We have. 3.0stable1 is out, 3.0stable2 now in
final stages before release. Roadmaps are being laid out for
predictability and followed. You were arguing for adding new things to
3.0 in order to encourage use of it, that adds instability, we will only
be adding new features to the latest 3.x release.

> performance
 - well, Adrian is the only 'expert' we have on this amongst the
developers. I play at it in -3. You will have to ask him to add some of
his work to -3.
I believe 3.x is now as performance-efficient as a 2.6stable 6 install.

> wide adoption (yes, this is a chicken-and-egg problem)
 - The usual basic problem, but its growing. 3.0 is the next step from
2.5, and those remaining installs are coming up.

Thank you. You have just doubled our public-submissions count.

>
>> Most of the developers are already working on this. We do want to
>> close
>> the divide. We also have not yet had a sponsor willing to pay
>> specifically
>> for any feature porting. So we are stuck with doing it whenever time
>> is
>> available.
>
> Again, parity with -2 isn't enough; why would someone pay for
> something they can already get in -2 if it meets their needs?
>
> You need to find a killer app for -3 that has broader appeal than just
> ICAP and ESI.

3.0 was about parity with needs. It failed some in that regard.
3.1 is about making up that failure plus some.
Is seamless IPv6, SSL control, and weighted round-robin not enough of a
killer app for you?

>
> While I'm in a mood for ruffling feathers (*grin*), it might also help
> to have the "core" discussions in public; AIUI there's a separate
> mailing list for this, and while having those discussions hidden away
> shelters you guys to some degree -- and I appreciate your motivation
> for doing so -- it also removes the opportunity for feedback by
> interested non-core folks. You might find that some more transparency
> improves the process and vitality of the project.

Well, to shed some light on things (I hate secrecy too). The core
discussions are all about what we are going to publicly say so we don't
contradict ourselves and confuse people too much. Often personal messages
between individuals. We ruffle each others feathers at times too. None of
which is something people exactly want public. The rest is going through
squid-dev and squid-users.

Amos
Received on Wed Mar 05 2008 - 18:28:13 MST