Greg, this seems OK to me. I don't think there will be a problem sharing the 
doc and build directories for multiple efforts.

On Monday, February 12, 2001, at 08:19 PM, Greg Stein wrote:

> 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 ] 
>  
> 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, [EMAIL PROTECTED] 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 Murcko
Topsail Group
http://www.topsail.org/

Reply via email to