[sorry for coming back to your post over and over, but I feel many of your
points are still hanging unanswered]
On Wed, 2 Nov 2005, Duane Wessels wrote:
> But on the other hand I feel cheated because I remember being scolded
> for adding things to the squid-2-head branch when others had decided
> that it would become a dead end.
If I remember correctly this accident was a feature added to Squid-2 only
and not Squid-3, and when development on Squid-2 HEAD had already been
abandoned by the others.
If Squid-2.6 gets on the schedule again it's reset with current Squid-2.5
as starting point (in fact Squid-2 HEAD has already been reset to reduce
confusion).
What we previously had in Squid-2 HEAD (aka Squid-2.6 at the time) before
it became Squid-3 is definitely a dead end as it contains a lot of
refactoring and restructuring which now belongs in Squid-3 only.
> Like you I suppose, I have a number of little 2.5 features and fixes
> that I use on my own squids, which I have been reluctant to commit for
> those reasons.
Would be interesting to know what features you use on top of 2.5.
> My company has taken on development projects with the understanding
> that all future work will go into squid-3. As part of that work
> we have promised spend time on making squid-3 stable. We still
> intend to do that.
And is the way it should be.
But my experience is that very few customers are willing to wait for
Squid-3 to become stable, instead demanding that the feature is also
developed for Squid-2.5 for production use "now" and in addition also to
Squid-3 to be future safe.
I also see that Squid is quite rapidly loosing it's presence on the market
in favor for our friend Apache for reverse proxies and a number of
commercial closed vendors for Internet proxies, in large due to Squid-2.5
starting to become quite behind in both functionality and performance
unless one is willing to spend a lot of time on patching (a situation not
to far from that of qmail I would say except that we at least have all the
major bugs fixed...)
Before making a final decision on the fate of Squid-2.6 perhaps we should
explore the time frame of Squid-3.0.STABLE a bit. I cannot claim that I
have a good picture of what it may take to get Squid-3 to the point of
Squid-3.0.STABLE, but my gut feeling is that there is a lot more work
remaining than one thinks at the first glance.
Last time I looked at the state of Squid-3 I got a bit scared finding
several major core refactoring and features being left hanging "in the
middle of getting done". The most notable in functionality being range
processing.
The main reason why I promote Squid-2.6 is mainly that we are already way
overdue on getting a new STABLE release and I also do not see a realistic
time frame when Squid-3 may become stable. The initially proposed
Squid-2.6 release can be done within a month making it quite tempting in
order regain interest in Squid, but I do not want to do this at the cost
of significantly delaying Squid-3.0.STABLE, at least not if
Squid-3.0.STABLE can be realistically seen within a not too distant
future.
As you and Alex are currently the only ones actively working on Squid-3
focused development you are probably the best to give a realistic estimate
on the timeframe of Squid-3.0.STABLE.
If Squid-3.0.STABLE is realistic within a not too distant future then
Squid-2.6 is not needed and would in fact hurt Squid in the long run, no
matter how temting the release it may be to myself and others.
If Squid-3.0.STABLE is not realistic in the near future (months, not
years) then the proposed Squid-2.6 in my eyes is highly needed, and would
in the long run probably allow Squid-3.0.STABLE sooner rather than later
even if there is some dissapointment with current sponsors.
Regards
Henrik
Received on Sun Nov 06 2005 - 16:35:50 MST
This archive was generated by hypermail pre-2.1.9 : Thu Dec 01 2005 - 12:00:15 MST