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

On Tue, 2008-03-11 at 10:57 +1100, Mark Nottingham wrote:

> It might be good to have a *little* more process around how ones
> sponsors changes in Squid -- whether -2 or -3 -- to assure that
> there's coordination between the feature sets, and that the entire
> Squid developer community is bought into the changes.

I agree. At London meeting, we made progress redesigning Squid support
infrastructure and there should be positive changes in that area soon.

As for coordination of the development, this is currently the
responsibility of the developer (sponsored or not), but the new
Feature-based Squid3 roadmap is a step forward to encourage early
discussion of planned features. With less than 10 active developers
working on Squid3, it is not difficult to inform others and get
feedback, provided the project is of interest to other developers.

> More detail on the roadmap would also be useful; potential sponsors
> need more information about what's involved in the changes, what the
> risks are, and how long it will take / how much it will cost.

I agree that if we start soliciting sponsorship for general-improvement
projects, we need to document and advertise them a lot better.

Currently, sponsors come with their specific needs and their designated
developer is responsible for providing estimates, including risk
assessment. If the project is approved, Squid3 developers should add it
to the roadmap, which triggers discussion and may affect the release
timeline. I think that works fairly well for sponsor-requested changes,
but improvement suggestions are very welcome.

> 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.

> as long as -3 doesn't block -2 (which AFAICT it wouldn't).

Yes, for better or worse, Squid3 folks are currently against
artificially blocking Squid2 as a way of resolving the two-version mess.

> I'm not willing to do that in perpetuity, though.

Yes, I think there is consensus that the current situation is a waste of
resources (at least), and nobody wants it to continue. Unfortunately,
there is no consensus on how to get out of this mess.

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.

Thank you,

Alex.

> On 08/03/2008, at 4:46 AM, Alex Rousskov wrote:
>
> >
> > Below you will find my personal comments on a few hand-picked thoughts
> > (from various posters) that I consider important on this thread:
> >
> > On Thu, 2008-03-06 at 08:44 -0800, Michael Puckett wrote:
> >> If there is one killer app that tops all other functionality
> >> additions it would be to multi-thread Squid so that it can
> >> perform on multi-cores.
> >
> > Ability to perform on multiple cores is a performance/scalability
> > optimization. We obviously do want Squid to perform and scale better,
> > and are working on that.
> >
> > Squid3 already has several mechanisms that would make such work
> > easier.
> > Folks that need faster Squid, including CPU-core scalability
> > optimizations, should consider contributing time or money to the
> > cause,
> > keeping in mind that it is a serious project and it will require
> > cooperation with other developers and projects.
> >
> >
> > On Thu, 2008-03-06 at 11:26 +1100, Mark Nottingham wrote:
> >> Again, parity with -2 isn't enough; why would someone pay for
> >> something they can already get in -2 if it meets their needs?
> >
> > Nobody should pay for something they do not need. However, any sponsor
> > should consider the long-term sustainability of an old or new feature
> > they rely on: Will the feature I need be included in the next major
> > Squid version? Do I need cooperation and trust of Squid developers?
> > Do I
> > want a fork dedicated to my needs? These questions are often as
> > important as the "How much would it cost me to make Squid do Foo by
> > the
> > end of the month?" question.
> >
> > Currently, sponsors have significant impact on Squid direction.
> > There is
> > a lot of implied responsibility that comes with that influence. Please
> > use your power with care.
> >
> >
> > On Thu, 2008-03-06 at 01:15 +0000, Dodd, Tony wrote:
> >> development on -3 seems entirely ad-hoc, with no direction; whereas
> >> -2
> >> development is entirely focused [...]. I could be talking entirely
> >> out of turn here though, as I haven't seen a -3 roadmap.
> >
> >> The second thing [...] the majority of squid developers don't seem to
> >> get, is that the big users of squid are businesses.
> >
> >> The truth of it is, as much as you guys tell yourselves that
> >> your userbase is people who run one or two cache boxes in their
> >> basements to cache their lan internet access, and that there's no
> >> money
> >> in squid, ...
> >
> >> I've spoken to Adrian too many times to count on two hands about this
> >> whole thing, and if you guys are trying to re-invent the wheel, you
> >> may as well stop now.
> >
> > I am not sure how to say this the right way, but when your opinion is
> > based on a single and often extremely biased source of information,
> > your
> > perception of reality becomes so distorted, that it is very difficult
> > for others to respond.
> >
> > Your assumptions about the "majority of squid developers" are simply
> > wrong.
> >
> > Believe it or not, we understand your situation fairly well. Nobody I
> > know is asking you to upgrade to Squid3, for example.
> >
> > What I would suggest is that you make a fundamental choice: Do you
> > want
> > to collaborate with the Squid project (as a whole)? If yes, we will do
> > our best to address your short-term and long-term needs. If no, I am
> > sure your dedicated developer will do his best to address your needs
> > within or outside the project.
> >
> > Collaborating with an open source project is difficult because you
> > have
> > to cooperate with others and balance different needs, all while
> > struggling with inefficiencies of a weak decision-making structure.
> > Whether collaboration benefits are worth the trouble, is something you
> > have to decide. I certainly hope they are.
> >
> >
> > On Thu, 2008-03-06 at 18:17 +0900, Adrian Chadd wrote:
> >> Mark Nottingham wrote:
> >>> A killer app for -3 would be multi-core support
> >>
> >> 12 months away on my draft Squid-2 roadmap, if there was enough
> >> commercial interest.
> >
> > 11 months away on Squid-3 roadmap if there is enough commercial
> > interest. And I will also throw in a 90% chance that the feature will
> > also be in Squid4 without a major porting effort. Wait, wait, and a
> > 10%
> > off coupon!
> >
> > But, really, this is _not_ the way Squid features should be planned or
> > sponsorship should be solicited, and I trust Adrian knows that.
> >
> >
> > On Thu, 2008-03-06 at 11:26 +1100, Mark Nottingham wrote:
> >> While I'm in a mood for ruffling feathers (*grin*),
> >> it might also help to have the "core" discussions in public
> >
> > Discussions that may benefit from public input should, and usually do,
> > happen on squid-dev or squid-users, even if they start on squid-core.
> > That covers the majority of the topics. There is not much "how the
> > Core
> > should respond?", "dirty laundry", "personal", or "offensive to
> > somebody" stuff that we have to keep private. Any multi-person
> > organization has these trust layers, naturally.
> >
> >
> > I hope the above comments will clarify my personal position. I would
> > love to work with more users that, besides pulling hard in their
> > direction, would think of the project as a whole, accepting the fact
> > that Squid will always try to satisfy several conflicting needs.
> >
> > The list of "missing" Squid3 features was a useful outcome of this
> > thread. I will make sure those wishes are added to Squid3 roadmap.
> >
> > If you have other specific suggestions on where and how the project
> > should move, there are developers willing to listen.
> >
> > Thank you,
> >
> > Alex.
Received on Mon Mar 10 2008 - 23:28:39 MDT