[STATUS] (apr-serf) Wed Sep 17 23:47:30 EDT 2003

[STATUS] (apr-serf) Wed Sep 10 23:47:42 EDT 2003

APR-SERF STATUS:						-*-text-*-
Last modified at [$Date: 2002/07/01 15:51:57 $]

Release:

RELEASE SHOWSTOPPERS:

	We need code.  This project's goal is to create an http
	client library.

  * web pages (go to apr-site)

  * decide on layout of the repository (e.g. subdirs)
    Greg thinks: prolly the following: /build, /include, /docs, /test, 
		 /core, and some for high-level items (maybe /filters
		 and /utils)
    Justin says: Fine with me except /core can't be used as autoconf
                 trounces this directory via rm -rf - how about /base?

  * set up config/build structure based on apr-util
    (take this opportunity to simplify again; hopefully to fold these
     simplifications back into apr(-util))

  * release scripts (in /build) (and a how-to-release.txt in docs/)

RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:

Underage drinkers read (fwd)

Okay, so this is annoying.  Mr. fakeidman here subscribed
fakeidman <at> fakeidman.org to various apache.org mailing lists apparently for
the sole purpose of submitting spams and having them go through
unmoderated.  The first copy of this spam hit dev <at> apr.  I then
unsubscribed the address from dev <at> apr.  Now it's serf-dev <at> apr.

Somebody remind me how to blacklist an address from all of apache.org?

Also, it would seem that the spammers are getting smarter and have come up
with a way to automate the subscribe-confirm-spam process.  Perhaps it was
manual, but that seems out of character for a spammer.  Anyway, I forsee a
downward spiral... 

--Cliff

---------- Forwarded message ----------
Received: from config.mail.Virginia.EDU (config.mail.Virginia.EDU
    [128.143.2.245])
	by ares.cs.Virginia.EDU (8.12.9/8.12.8/UVACS-2003031900) with ESMTP
    id h87JxtqU027016
	for <jcw5q <at> cs.Virginia.EDU>; Sun, 7 Sep 2003 15:59:55 -0400 (EDT)
Received: from cgatepro-3.mail.virginia.edu (guppy.mail.Virginia.EDU
    [128.143.2.218])
	by config.mail.Virginia.EDU (8.9.3p2/8.9.3) with ESMTP id PAA18216
	for <jcw5q%cs.virginia.edu <at> cmsrelay.mail.virginia.edu>; Sun,
     7 Sep 2003 15:59:55 -0400 (EDT)
Received: from <jcw5q <at> cgatepro-3.mail.virginia.edu>
  by cgatepro-3.mail.virginia.edu (CommuniGate Pro RULES 4.1)
  with RULES id 55935400; Sun, 07 Sep 2003 15:59:55 -0400

[STATUS] (apr-serf) Wed Sep 3 23:46:24 EDT 2003

APR-SERF STATUS:						-*-text-*-
Last modified at [$Date: 2002/07/01 15:51:57 $]

Release:

RELEASE SHOWSTOPPERS:

	We need code.  This project's goal is to create an http
	client library.

  * web pages (go to apr-site)

  * decide on layout of the repository (e.g. subdirs)
    Greg thinks: prolly the following: /build, /include, /docs, /test, 
		 /core, and some for high-level items (maybe /filters
		 and /utils)
    Justin says: Fine with me except /core can't be used as autoconf
                 trounces this directory via rm -rf - how about /base?

  * set up config/build structure based on apr-util
    (take this opportunity to simplify again; hopefully to fold these
     simplifications back into apr(-util))

  * release scripts (in /build) (and a how-to-release.txt in docs/)

RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:

[STATUS] (apr-serf) Wed Aug 27 23:46:44 EDT 2003

APR-SERF STATUS:						-*-text-*-
Last modified at [$Date: 2002/07/01 15:51:57 $]

Release:

RELEASE SHOWSTOPPERS:

	We need code.  This project's goal is to create an http
	client library.

  * web pages (go to apr-site)

  * decide on layout of the repository (e.g. subdirs)
    Greg thinks: prolly the following: /build, /include, /docs, /test, 
		 /core, and some for high-level items (maybe /filters
		 and /utils)
    Justin says: Fine with me except /core can't be used as autoconf
                 trounces this directory via rm -rf - how about /base?

  * set up config/build structure based on apr-util
    (take this opportunity to simplify again; hopefully to fold these
     simplifications back into apr(-util))

  * release scripts (in /build) (and a how-to-release.txt in docs/)

RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:

[STATUS] (apr-serf) Wed Aug 20 23:46:39 EDT 2003

APR-SERF STATUS:						-*-text-*-
Last modified at [$Date: 2002/07/01 15:51:57 $]

Release:

RELEASE SHOWSTOPPERS:

	We need code.  This project's goal is to create an http
	client library.

  * web pages (go to apr-site)

  * decide on layout of the repository (e.g. subdirs)
    Greg thinks: prolly the following: /build, /include, /docs, /test, 
		 /core, and some for high-level items (maybe /filters
		 and /utils)
    Justin says: Fine with me except /core can't be used as autoconf
                 trounces this directory via rm -rf - how about /base?

  * set up config/build structure based on apr-util
    (take this opportunity to simplify again; hopefully to fold these
     simplifications back into apr(-util))

  * release scripts (in /build) (and a how-to-release.txt in docs/)

RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:

snapshot download url

To accomodate a project I am working on, I have put up a auto-syncing
snapshot download. It checks out anoncvs twice a day from:
	:pserver:anoncvs <at> cvs.apache.org:/home/cvspublic
and tars it up as apr-serf_snapshot.tgz
here:

	http://node.to/mirror/src/apr-serf_snapshot.tgz

I've written an apache module that provides a full feature load balancer,
and am finding the apr-serf library very handy in writing a monitoring and
management utility (the module is manageed via http requests to it).

  mark <at> node.to  http://node.to/~mark   7123 3F7B 10EC 7122 2F8B
  http://node.to/keys/mark.asc         B474 B09D 6ED7 3FB0 09E8

[STATUS] (apr-serf) Wed Aug 13 23:47:31 EDT 2003

APR-SERF STATUS:						-*-text-*-
Last modified at [$Date: 2002/07/01 15:51:57 $]

Release:

RELEASE SHOWSTOPPERS:

	We need code.  This project's goal is to create an http
	client library.

  * web pages (go to apr-site)

  * decide on layout of the repository (e.g. subdirs)
    Greg thinks: prolly the following: /build, /include, /docs, /test, 
		 /core, and some for high-level items (maybe /filters
		 and /utils)
    Justin says: Fine with me except /core can't be used as autoconf
                 trounces this directory via rm -rf - how about /base?

  * set up config/build structure based on apr-util
    (take this opportunity to simplify again; hopefully to fold these
     simplifications back into apr(-util))

  * release scripts (in /build) (and a how-to-release.txt in docs/)

RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:

[STATUS] (apr-serf) Wed Aug 6 23:46:47 EDT 2003

APR-SERF STATUS:						-*-text-*-
Last modified at [$Date: 2002/07/01 15:51:57 $]

Release:

RELEASE SHOWSTOPPERS:

	We need code.  This project's goal is to create an http
	client library.

  * web pages (go to apr-site)

  * decide on layout of the repository (e.g. subdirs)
    Greg thinks: prolly the following: /build, /include, /docs, /test, 
		 /core, and some for high-level items (maybe /filters
		 and /utils)
    Justin says: Fine with me except /core can't be used as autoconf
                 trounces this directory via rm -rf - how about /base?

  * set up config/build structure based on apr-util
    (take this opportunity to simplify again; hopefully to fold these
     simplifications back into apr(-util))

  * release scripts (in /build) (and a how-to-release.txt in docs/)

RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:

[STATUS] (apr-serf) Wed Jul 30 23:46:44 EDT 2003

APR-SERF STATUS:						-*-text-*-
Last modified at [$Date: 2002/07/01 15:51:57 $]

Release:

RELEASE SHOWSTOPPERS:

	We need code.  This project's goal is to create an http
	client library.

  * web pages (go to apr-site)

  * decide on layout of the repository (e.g. subdirs)
    Greg thinks: prolly the following: /build, /include, /docs, /test, 
		 /core, and some for high-level items (maybe /filters
		 and /utils)
    Justin says: Fine with me except /core can't be used as autoconf
                 trounces this directory via rm -rf - how about /base?

  * set up config/build structure based on apr-util
    (take this opportunity to simplify again; hopefully to fold these
     simplifications back into apr(-util))

  * release scripts (in /build) (and a how-to-release.txt in docs/)

RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:

[STATUS] (apr-serf) Wed Jul 23 23:46:12 EDT 2003

APR-SERF STATUS:						-*-text-*-
Last modified at [$Date: 2002/07/01 15:51:57 $]

Release:

RELEASE SHOWSTOPPERS:

	We need code.  This project's goal is to create an http
	client library.

  * web pages (go to apr-site)

  * decide on layout of the repository (e.g. subdirs)
    Greg thinks: prolly the following: /build, /include, /docs, /test, 
		 /core, and some for high-level items (maybe /filters
		 and /utils)
    Justin says: Fine with me except /core can't be used as autoconf
                 trounces this directory via rm -rf - how about /base?

  * set up config/build structure based on apr-util
    (take this opportunity to simplify again; hopefully to fold these
     simplifications back into apr(-util))

  * release scripts (in /build) (and a how-to-release.txt in docs/)

RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: