Broken configure script in Squid 2.6, for FreeBSD

2006-09-11 Thread Anders Nordby 
Hi,

It seems that configure.in is broken for FreeBSD:

- If you build Squid using the ports system on FreeBSD, target is set to
${ARCH}-portbld-freebsd${OSREL}.

- FreeBSD is a multi-platform OS. Especially amd64 is common these days.

Please apply the attached patch upstream.

Thanks.

Cheers,

-- 
Anders.
--- configure.in.orig   Mon Sep 11 09:08:36 2006
+++ configure.inMon Sep 11 09:10:21 2006
@@ -1994,7 +1994,7 @@
*-sun-solaris*)
  echo skipping libmalloc check for $host
;;
-   i386-*-freebsd*)
+   *-freebsd*)
  echo skipping libmalloc check for $host
;;
*)
@@ -2033,7 +2033,7 @@
 if test $with_pthreads = yes; then
 CFLAGS=$CFLAGS -D_REENTRANT
 case $host in
-i386-unknown-freebsd*)
+*-freebsd*)
if test $GCC = yes ; then
if test -z $PRESET_LDFLAGS; then
LDFLAGS=$LDFLAGS -pthread

Re: 3.0 branding - release plans - etc

2006-09-11 Thread Duane Wessels 




On Sun, 10 Sep 2006, Robert Collins wrote:


So, chatting with Adrian today, and some friends, I have some thoughts
about what precisely 3.0 should be.

I think 3.0 STABLE1 when release should be:
* more functional than 2.6 STABLEX - there should be no regressions in
functionality.
* within 10-15% of the speed of 2.6 STABLEX.


Does this mean +/- 10-15%?

In order to meet the goal we'll need a measurable definition for
speed.  I assume that you're thinking along the lines of sustained
requests/second within some response time window?  Which OS, and
which filesystem options?


these two points are the primary things I can think of that will stop
people adopting squid-3.0. And what we want is for developers to feel


I would probably put stability ahead of performance, but yes, assuming
squid-3 is stable enough then people will expect it to perform at least
as well as the old.

DW

Re: 3.0 branding - release plans - etc

2006-09-11 Thread Robert Collins 
On Mon, 2006-09-11 at 16:57 -0600, Duane Wessels wrote:
 
 
 On Sun, 10 Sep 2006, Robert Collins wrote:
 
  So, chatting with Adrian today, and some friends, I have some thoughts
  about what precisely 3.0 should be.
 
  I think 3.0 STABLE1 when release should be:
  * more functional than 2.6 STABLEX - there should be no regressions in
  functionality.
  * within 10-15% of the speed of 2.6 STABLEX.
 
 Does this mean +/- 10-15%?

If 2.6-LATEST_STABLE has a sustained request rate of 8000 4k requests
per second, then by 'within 10-15%' I mean:
3.0 should have a sustained request rate in the same scenario of no less
than 6800 4k requests per second.

 In order to meet the goal we'll need a measurable definition for
 speed.  I assume that you're thinking along the lines of sustained
 requests/second within some response time window?  Which OS, and
 which filesystem options?

I think 2.6 and 3.0 should be relatively close on that - so say 'linux,
epoll, aufs'. Or perhaps we should have a few scenarios.

  these two points are the primary things I can think of that will stop
  people adopting squid-3.0. And what we want is for developers to feel
 
 I would probably put stability ahead of performance, but yes, assuming
 squid-3 is stable enough then people will expect it to perform at least
 as well as the old.

Yah, thats pretty much my feeling.

-Rob
-- 
GPG key available at: http://www.robertcollins.net/keys.txt.


signature.asc
Description: This is a digitally signed message part