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

On Mon, 2008-03-10 at 22:38 -0800, Michael Puckett wrote:
> I'll come back to one of Mark's earlier points then which seems to have
> been lost. What will decide on adoption of -2 or -3 is the "killer app".

That point has not been lost. There are two distinct problems here:
First, "the killer app is Foo" predictions differ and (looking back) are
often wrong. Second, even if we agree what a killer app will be, we may
not have the resources to implement it without more sponsorship,
especially when the development is split between the two versions.

Let's take scalability with CPU cores as an example (without making a
statement that this is the [only] killer app for Squid). Any sane
developer wants scalability. It has been on the roadmaps for years[1].
To actually implement this feature you need an agreement among
developers on how to do it and the funding to do the coding. If we
combine existing Squid2 and Squid3 funding streams, there is probably
enough money to fund the development. I suspect developers can agree on
how to implement it as long as nobody insists on a yet another rewrite
of Squid code.

As you can see, if there was an agreement on how to merge Squid2 and
Squid3 development, the funding streams would merge as well, and
improvements like SMP scalability would come out faster.

> Users don't care if the project is recoded in C++ to make the developers life
> easier, the developers do, so that is not compelling in the slightest as
> a reason to migrate. Which I know you already realize.

Yes, but what is missing in the above argument is that you get more
Squid3 developers and reduced danger of significant migration costs down
the road. Users do not care about programming languages, but many care
about support and sustainability of the features they want or depend on.

> IMHO I still think that Mark was right that (at least one) killer app is
> a true multi-threaded application that can take advantage of current HW
> today. Now. I think that the current squid is exposed and probably
> vulnerable if a competing project comes out that takes full advantage of
> current HW and significantly outperforms todays non-scalable squid. If
> that happens the entire -2, -3 argument is moot. Just my $0.02 though.

Sure, we realize that there is (and always will be) competition. We need
to focus on specific/pragmatic steps to move forward though. Currently,
we are moving forward at 1/3 of the speed that would have been possible
with the same resources because we split the effort and then (some of
us) spend time trying to merge it back. This does not make the project
more competitive.

If we want to move at full speed, we need to agree on a single roadmap.
Since we failed to reach that agreement among the active developers, I
suggest that sponsors that want a single roadmap join and help us to
resolve the deadlock.

Thank you,

Alex.
[1] I just made that wish more explicit to avoid any misunderstanding
that SMP scalability is what we want, with some rough indication of a
timeline: http://wiki.squid-cache.org/Features/SmpScale

> Adrian Chadd wrote:
> > On Mon, Mar 10, 2008, Alex Rousskov wrote:
> >
> >
> >>> WRT responsible sponsoring: I'm willing to pay a (reasonable) premium
> >>> to get the things that I pay to get into -2 into -3 as well,
> >>>
> >> Thank you, and I am sure many sponsors would do the same if the
> >> trade-offs are explained to them correctly. Unfortunately, I have so far
> >> failed to convince the most prolific Squid2 developer to accept this as
> >> the default model and encourage its use.
> >>
> >
> > Because I'm still not 100% convinced that the Squid-3 codebase is really
> > the "way forward".
> >
> > I shouldn't have been the one that tried to pull some sensible direction and
> > feedback into the development group - those working and pushing Squid-3 should've
> > been doing that already. Unfortunately until very recently there has been
> > almost no public dialogue that I could see.
> >
> > My concern is about project direction and sustainability. I chose to do
> > my work on Squid-2 in mid to late 2006 because:
> >
> > (a) it was stable, so I didn't have to worry (as much) about whether bugs
> > were due to me or pre-existing code;
> > (b) it was in wide use by people, so incremental improvements could be
> > adopted by existing sites without as much fear as trying to push Squid-3
> > as a platform;
> > (c) I wasn't sure at the time whether there was enough momentum behind Squid-3
> > to justify investing time in something that may never be as prolific as
> > -2; and I wasn't willing to invest even more of my time trying to drag the
> > codebase forward.
> >
> > I shouldn't have had to try and kick Squid-3 developers along to do simple things
> > like regression testing and local benchmarking; I shouldn't have to try and explain
> > that the model of "do whats interesting to you and what you're being paid for"
> > is such a great idea as a project direction; I shouldn't have to try and
> > explain why an architecture and a roadmap is a great idea for a software project.
> >
> > I doubly shouldn't have to try and convince the Squid-3 developers considering
> > the -past history of the whole effort-.
> >
> > This is why I'm not all that interested right now in doing very much in relation
> > to Squid-3.
> >
> > As I said on squid-core, my opinion may change if - and I stress _if_ - changes
> > to the project structure and direction occur which I see improving things.
> > I don't mean "improving the paid project quota on Squid-3"; I mean things like
> > improvements in direction, collaboration, documentation, testing and communication.
> >
> >
> >> Personally, I would love to see active sponsors together with active
> >> developers agreeing on a pragmatic migration plan towards a single Squid
> >> roadmap. I would be happy to facilitate such discussions. The active
> >> developers alone have so far failed to reach such an agreement, but I
> >> think direct Squid2 sponsor participation may help resolve the deadlock.
> >>
> >
> > To be honest about it, the only dissenter now is me. I'm not sure whether my
> > continued dissent is a good idea for the project, but thus far the feedback
> > I've received has been 100% positive. I'd like to keep kicking along Squid-2
> > until the point where a future Squid code tree is attractive enough to replace
> > it. And I'm going to keep dissenting until I see the fruits of actual change,
> > not just the discussion of it.
> >
> >
> >
> >
> > Adrian
> >
> >
Received on Tue Mar 11 2008 - 09:33:56 MDT