On Thu, May 08, 2008, Amos Jeffries wrote:
> > On Wed, May 07, 2008, Christian Seifert wrote:
> >> Or if you could merge 2.7 into 3.0, that would also help. Seems like 3.0
> >> currently doesnt have the storeurl_program options....
> >
> > When the 3.0 developers push out a stable tree which people can move
> > to, sure, I'll look at merging stuff of mine into -3.
> >
> > But right now I don't find -3 "fun" to work on,
>
> There you have the crux of the entire (5 year?) Squid-2 vs Squid-3 debate.
> Adrian doesn't find C++ code 'fun'.
Hey cool! Somehow it became about C++.
No, I don't find the development direction, the lack of meaningful pre-planning
except when commercial interests are involved, the lack of useful large-scale
user deployment feedback (and the lack of community participation in general is
another topic, but I digress) and the fact that the codebase combines the worst
bits of C and C++ in a monolithic, semi-structured mess "fun".
I find it "fun" that companies like Yahoo, last.fm and Wikipedia still run Squid-2
in large scale production, and that the improvements I make in whatever I choose
to work on in my spare time are involved in the day-to-day experiences of millions
of people, even though none of them know about it.
I find it "fun" that I can take a legacy bit of software and start to modernise
it, far past what current user expectations are. I know I'm reinventing the wheel
somewhat, but I find trying to reinvent the wheel whilst not reinventing the wheel
a "fun" challenge.
I started Xenion to try and turn some of that "fun" into something worthwhile,
so I could spend more of my time working on things which may make a bit of
a difference.
> > and commercial work
> > aside, I still hack on Squid for fun. Commercial work not aside,
> > I don't agree with the directions that -3 is currently taking, and
> > until there's a more sensible and stable codebase I can't justify
> > suggesting that {current, new} clients migrate to Squid-3.
>
> Come on, define 'sensible code' and stability for the readers please.
> 2.7 is less stable than 3.0 at present. The old roadmap from 2.7 to 2.8
> included sweeping core changes more destabilising than the 3.0->3.1 ones.
Weird! 2.7 is stable enough, and faster, and the few bugs introduced are being
ironed out. Just like in 3.0. Except, 3.0 -> 3.1 is a large jump, and 3.1 -> 3.2
is going to be an even larger jump. The last couple of 2.7 bugs have been due to
recent additions on contract; and Henrik's found and squished those.
I personally think 2.7.STABLE1 should've been released a couple of months ago.
As it stands right now, I think 2.7 is going to match and exceed stability and
performance expectations from Squid-2.6, and thats what I find "fun".
Study 2.7 to 2.HEAD; the changes aren't all that drastic. The biggest drastic
change is the elimination of the store -> client copy, which yes there are bugs,
but they're being worked out.
Insted of trying to squeeze more into Squid-2.HEAD (and Cacheboy, for that
matter), I've put a hold on any of my work that'll destabilise things further.
I spent time working in a sandbox to see exactly how far I could get with
sweeping changes; I took notes, I learnt from the experience, and the stuff
thats different between 2.HEAD and Cacheboy right now represents what I've
learnt from that experience.
Check out the Cacheboy stuff - that includes a lot of the changes which I
was going to make along the Squid-2.8 roadmap, and almost none of the changes
were dramatic. Code reorganisation, code tidyup, replace a FIFO implementation
with something slightly more sensible. Break out the code in preparation for
further development and testing work. All the stuff that we should've done years
ago, except the focus shifted to -3 and, and I'm going to really honest here,
it never delivered.
Sensible code: modular, well-defined APIs, try to remove legacy stuff whilst
maintaining stability. Squid-2 and Squid-3 haven't tackled the big issues
in the codebase, and it doesn't seem like Squid-3 will tackle any of those
issues any time soon.
So no Amos, I don't buy the "2.7 to 2.HEAD is just as destabilising as 3.0
to 3.1" line. I believe that anyone who bothers reading the code/changesets will
come to the same conclusion.
> >From the stats 12% of the squid users (on Linux with basic packages) are
> using 3.0 now over all versions of 2.x. _On_top_ of the 10% increase in
> total users 2.x (all versions) had over the period since 3.0 was released.
Origin please. I bet you can attribute a large part of that to people who
run the "latest" version of software, and Squid-3 probably runs fine for
them.
> > (This is why I forked off Squid-2 into Cacheboy, btw.)
>
> And why we concreted, tested, and fixed up squid-3 to released 3.0 full of
> the existing stable changes. Prior to adding much of the fancy new stuff
> from 2.6, 2.7, 2.8, and 2.9.
The stuff was added to 2.x because people wanted/coded it. You know, because
people are actively using it and stuff.
> We in squid-3 agree with you Christian. If only the 2.6 and 2.7 changes
> were also ported to 3.x when they had passed testing in 2.x there would be
> not quite such a mess of shifting goalposts and last-minute catchup
> features plugged on top of (de-stabilizing!) 3.1.
Hey, I'm really sorry that the stuff _I_ did for fun in a _stable_ codebase
weren't done in an _unstable_ codebase which I then couldn't really suggest
that people try out in production. I'm also sorry for those feature submissions
for Squid-2.6 and Squid-2.7 - obviously thats not what people want to use.
Its the Squid-3 developers' choice to throw stuff into 3.1 to try and become
feature-par with Squid-2. Hey, I'm all for that, but there's so much crap
in the Squid-ALL codebases which need tidying up before the codebase can really
shine, and I'm quite frankly fed up waiting for the right oppertunity to do it.
Its crap like this which makes me simply want to quit developing Squid again.
Adrian
