Re: squid-3 vs 2.6

Hi Henrik,

At 23.28 24/06/2006, Henrik Nordstrom wrote:

>lör 2006-06-24 klockan 18:57 +0200 skrev Guido Serassio:
>
> > Here I agree about the reasons, but I am doubtful about a 3.0 with
> > not all the 2.6 features:
>
>It's a simple matter or project priorities. With no doubt the absolutely
>highest priority for Squid-3 must be get a stable release out as soon as
>possible. The more new features added the longer this will take.

Sure, I agree about this.

> > why someone will "downgrade" its proxy ?
>
>Why not? And if they don't want to they have the choice of making sure
>they don't need to.
>
>Why is Squid-3 completely outside it's original release plan, and still
>no-one knowing when it's reasonable to expect a stable release?

You wrote "The 2.6 release is actually about focusing the community again".
This is happening because 2.6 include a lot of
feature needed in real production environments,
features already developed for 2.5 often with a customer sponsorship.
But I'm not so sure that the current feature set
of 3.0 could generate the same attention in the
community: the general lack of sponsorship for
the development of 3.0 features (with the
exception of ESI and ICAP) is a worrying signal.

> > Just for example: all my customers are waiting for connection pinning
> > with open arms ....
>
>Then I am pretty sure at least one of them is willing to sponsor the
>development and bug fixing required to get that feature in squid-3,
>making it available as a patch to the Squid-3.0 release early on, and
>then merged into 3.1.

Currently Italy is a worse market for Open Source Development:

The majority of the company are too little to
support any kind of sponsorship, while the whole
national economy is still near to recession.

Today in Europe only Greece if worse than Italy .... :-(

>Or if you prefer spending your time implementing the connection pinning
>for 3.0 instead of fixing bugs then you are very welcome to. When
>complete and tested in production it's a candidate for merging. If good
>it may make it into 3.0, else 3.1.

This could be the only feasible way, but for me
there is only a problem here: C++ ...... :-(
But this is OT to this thread ...

> > I remember the proposal when 2.6 work was announced:
> >
> > 1) 3.0 initially mainly for high end reverse proxies (ICAP & ESI) and
> > 2.6 for forward proxies
> > 2) 3.1 for both usage with all features.
>
> > It seems to me a good compromise for a customer.
>
>I am not sure even 3.1 will be 100% feature complete. I don't think we
>as a team can bind to that promise as it's very dependent on what other
>tasks each of us take for the 3.1 release.
>
>The most important is that we make progress. If this means some features
>is deferred so be it. There is no sponsor behind this project who work
>on such generic scale as "feature complete". Customers mostly pay for
>what they need, i.e. bug fixing of the issues they run into or features
>they need.

This one of the reasons because I like to have a
3.0 release mainly focused on its new features
related to reverse proxies, it will be the only
way to justify a feature limited release to the community and to customers.
I think that to ask to a customer a sponsorship
for the forward port into 3.x of a feature
already available in 2.6 is not a good product marketing ....

>Outside that we can not force anything on anyone else than
>yourself.
>
> * Any release plans depending on forcing something to get done is a
>risky one.
> * Open Source development works by interest, not force.
> * The single thing holding Squid-3 back is the fact that it's not
>stable. Until Squid-3 is stable it's very hard to shift development over
>there, and even harder to draw customer attention.

Sure, it's not mandatory (and cannot be) to have
a 3.1 release 100% feature complete, it could be
a 3.x as well. But before of a feature complete
stable 3.x release, we will have always a 2.x
release needing to be maintained and eventually
developed, with more wasting of our limited developing capability.

We are in a very ugly stall situation.

Regards

Guido

-
========================================================
Guido Serassio
Acme Consulting S.r.l. - Microsoft Certified Partner
Via Lucia Savarino, 1 10098 - Rivoli (TO) - ITALY
Tel. : +39.011.9530135 Fax. : +39.011.9781115
Email: guido.serassio@acmeconsulting.it
WWW: http://www.acmeconsulting.it/
Received on Sun Jun 25 2006 - 02:58:13 MDT