Re: feature freeze

[Randy Terbush <ra...@zyzzyva.com>]

> I just discovered I have to deal with something over the next few days
> that's going to take me offline.  Plus I start my new job on Monday.  I
> have the following in various states of completion: 
> 
> - 64bit cleanup, we're still debating it (I don't really care much about it,
>     I just want to get rid of the warnings)
> 
> - directory_walk optimization
> 
> - mod_cgi cleanup, and hopefully fixing the "user stops transfer, but cgi
>     keeps running" bug
> 
> - child_main tweaks and exponential spawning model (these are what you
>     would call "optimizing for benchmarks"; the first is a pure
>     optimization, the second is something that means we don't have to
>     worry about brain-dead reporters doing lame-ass reviews without
>     pre-tuning the server).
> 
> And I had planned to start these this week:
> 
> - reliable piped logs
> 
> - cleaner support in buff.c for mmaped files -- essentially using writev()
>     earlier so that we don't have to copy any data around in userspace.
>     Once this is done a mod_mmap.c can be written which handles */*...
>     mod_mmap will require tuning/tweaking on each operating system, so
>     I'm not planning it to be part of the standard set initially...
>     I just want the support in the core that it needs.
> 
> Can I have an extension for these until Aug 15th?  Release 1.3b1 on
> schedule, there'll probably be enough bug fixes to deal with for just the
> NT stuff to make it worthwhile. 
> 
> >From a performance point of view I think we want the above things in there
> so that we start kicking butt in reviews; the other half of doing well on
> reviews is the gui work... and I'm not sure how it fits into the schedule. 
> 
> Dean

All of this stuff easily justifies extensions/flexibility in the 
freeze.

Regarding the GUI stuff, I think (as others have mentioned) that we 
need to get a web based install processes added to the system as a 
first cut to a GUI.