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