Re: any objections to moving out modules/proxy?

Between myself, Ryan, and Chuck, there are three +1 votes. I'll probably do the move later on tonite (after the 1am PST time that I mentioned).

I'll set up a STATUS file with Ryan's set of benchmarks.

I'm considering the following layout:

/home/cvs/httpd-proxy/

    build/
    docs/
    module-2.0/ # mod_proxy for Apache 2.0

If the mod_proxy developers want to spin up separate efforts, they can create other subdirs. Maybe have a mod_revproxy or mod_cacheproxy or whatever. If mod_proxy is split into a few modules, they can also go in as subdirs.

Please provide feedback since it is easier to move files to the right place now, rather than later.
[ actually, you can do a lot of moving later if you aren't worried about   snapshot consistency for a given tag; you'll probably not have *any* tags   for a while, so it may be okay ]

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related httpd.apache.org Links announce bugs cvs dev docs gui-dev modproxy-dev packagers testers Request more information about Pantek

The top-level, build, and docs directories will be empty since a new system will need to be put into place. I would recommend looking at the apr-util build directory for a template. The buildconf and configure scripts should be quite simple, since you'll just be setting options rather than portability stuff (since that is solved by APR). You should use libtool, so the module will be built the same as Apache (you won't need to fetch a lot of Apache-specific flags and stuff via apxs). Basically: there will be a bit of rampup (downtime) to get mod_proxy building on its own, but it shouldn't be too bad. I'd also recommend that you don't worry about static Apache builds for now; it is a very difficult issue for externally-built systems.

After the move, then additional committers can be added as needed. That can be done with a request to the HTTPD PMC (I imagine Chuck will be making these requests). This process is still a bit TBD, as the proxy subgroup will need to get itself into working shape. I will also posit that the PMC won't have any problem adding committers recommended by Chuck, so you just have to sell yourself to him :-)

Cheers,
-g

On Sun, Feb 11, 2001 at 02:27:03AM -0500, Chuck Murcko wrote:
> On Saturday, February 10, 2001, at 12:01 PM, rbb@covalent.net wrote:
>
> > On Sat, 10 Feb 2001, Greg Stein wrote:
> >
> > > Great. We had a big discussion, and it has died off without any voting. The
> > > problem is that abstention doesn't tell us what to do, one way or the other.
> > > Let's try another tack:
> > >
> > > modules/proxy/ will move to its own CVS module sometime Tuesday or
> > > Wednesday (i.e. I'll get to it one of those two days)
> > >
> > >
> > > That leaves you through Monday (let's say Tuesday 1am) to state your vote.
> > > You can vote on the list, or in STATUS.
> >
> > Well, I'm guilty of abstaining, because I wanted to let other people make
> > the decision, but since that tack didn't work, +1 for moving the
> > code. However, before we do that, I would like to come up with some
> > benchmarks that would allow it to be moved back into the code. That will
> > encourage people to work on the code, because we are giving them a way to
> > get it back in the code, and it enforces the idea that we aren't dropping
> > the code, we are trying to help it.
> >
> > Those benchmarks could be as simple as:
> >
> > 1) The code compiles are runs as often as any code in the tree
> > 2) The functionality makes sense for an HTTP proxy
> > 3) There is an active maintainer who is or can become an ASF
> > member.
> >
> > Just some ideas off the top of my head. Whatever benchmarks we choose
> > should be in the STATUS file for mod_proxy, unless the mod_proxy people
> > want to remove them.
> >
>
> Works for me. Put 'em in there, along with the three simple goals from
> mod_proxy.h. +1 on moving the code. Just make the benchmarks clear, as Ryan
> suggests.
>
> Chuck
>
> Chuck Murcko
> Topsail Group
> http://www.topsail.org/

-- 
Greg Stein, 
http://www.lyra.org/