>
> > > It's more than just sendfile. When we compiled apache with -pthread,
and
> > > using the prefork MPM, we had threads go off to no-where. I am not
> > > willing to say we can't go beta until apache.org is running a threaded
> > > MPM, because that may not be possible.
> > >
> > > Also, this isn't our model anymore, and this discussion should be on
> > > new-httpd, not members.
> > >
> >
> > Ooops, new-httpd dropped out of my first reply to this thread. Apologies.
> >
> > Humm, I believe I implicitly assume a release status of "beta" is
basically a
> > statement regarding "quality" of the server ("Quality" in the sense of
"Zen
> > and the Art of Motorcycle Maintenance"). Is this not the model we are
> > following? My goal was to get a threaded server running to facilitate
driving
> > bugs out of that MPM; improving the quality of a major feature of Apache
2.0.
> > If "beta" status is not a statement of quality, then I don't understand
why we
> > go to the trouble of making the designation in the first place. Perhaps I
> > should write up a neat little random naming facility that makes up status
> > names. Next release can be alpha 1000, then maybe beta 75, then golden
> > followed by alpha centauri :-)
>
> I am having a hard time understanding why we are requiring our first beta
> to be seg fault free as well. The server works. It has been running on
> apache.org for at least four or five days. This is not GA code. We are
> stable, and things seem to work. A beta cycle means just that. We
> believe this is better than alpha code, but not quite completely finished,
> use at your own risk.
>
> If we wait until the code has zero problems, then what is the benchmark
> for GA code?
>
I agree the prefork MPM is definitely ready for beta. mpmt-pthread is the
default Unix MPM (as it should be IMO) and I'd -like- to see it tested the
same way as we are testing prefork now. Since threads and FreeBSD don't mix
too well, we don't have that option. +1 on releasing beta 1.
Bill
