Mailing List Archive

At 03:05 PM 10/19/95 MDT, you wrote:
>
>Does anyone consider the bugs being fixed by patches in /for_Apache_0.8.15
>to be showstoppers?

Hmmm.. I guess this depends on your site. Some people need
the symbolic links to work, some need .htm files to come up.
Different degrees.

>
>So I vote +1 on a release of 0.8.15 under the version
>number 1.0 this Sunday...
>
>vote or veto please.

+1 Here. Let get the sucker out the door already. Do we have any
patches against 0.8.15 yet?

<Aram>
--
Aram W. Mirzadeh, MIS Manager, Qosina Corporation
http://www.qosina.com/~awm/, awm@qosina.com
Apache httpd server team http://www.apache.org

>
> David's svr4 patch is a showstopper for some OSs, like newer UnixWare, so
> I'd suggest including that, anyway.
>
> +1 with that stipulation.

The same applies to the QNX patch.

>
> Rob Hartill liltingly intones:
> >
> >
> > Does anyone consider the bugs being fixed by patches in /for_Apache_0.8.15
> > to be showstoppers?
> >
>
> chuck
> Chuck Murcko Telebase Systems, Inc. Wayne PA chuck@telebase.com
> And now, on a lighter note:
> Who's on first?

--
Ben Laurie Phone: +44 (181) 994 6435
Freelance Consultant Fax: +44 (181) 994 6472
and Technical Director Email: ben@algroup.co.uk
A.L. Digital Ltd,
London, England.

Well, I'd prefer to hold off until we have a good release candidate
(the svr4 patch at least seems to be needed), which has had a public
tryout (NB 0.8.14 is still the default public release) --- just
because we're near the end of this road isn't a reason to test new
code any *less*.

(It may help to remember the poor slob at AT&T who spotted something
obviously wrong with the ESS code he was working on, and dropped in
a simple fix which clearly improved the situation. The code was so
obviously correct that it didn't need the full battery of tests; it
was just dropped into the system, and seemed to be working fine until
it brought down the entire AT&T long-distance network).

At the very least, let's have whatever we're going to release as 1.0
up as a public release for a couple of days first --- NB 0.8.15 still
is not. If we're going to have a revised set of docs, I'd also prefer
to wait until those have had a group review, to chase out what
typographical errors may have crept in... there are few things that
look less professional than doc bugs (say, the omission of a crucial
"not", which I can say from experience is all too easy to commit), and
avoiding that is worth some time and effort.

rst

>
>
> > >
> > > David's svr4 patch is a showstopper for some OSs, like newer UnixWare, so
> > > I'd suggest including that, anyway.
> > >
> > > +1 with that stipulation.
> >
> > The same applies to the QNX patch.
>
> If it's a showstopper, then the comments to describe it fail to convey that...
>
> *********************************************************************
> Comments: This patch also removes some redundant headers (not gratuitously,
> ^^^^^^^^^^^^^^^^^
> they had to go on QNX anyway, and were already included in some other
> local header). It also adds a debugging convenience; SIGSEGV and SIGBUS
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> are not caught when in debug mode (-X flag). This makes running under
> some debuggers better.
> *********************************************************************
>
>
> Those statements don't suggest any kind of urgency.
> I suppose the "This patch also" is the key phrase there.

Also the "Comments:" as opposed to "Changelog:". Though whether there is any
justification for splitting comments from change logs is another question.

>
> Can you strip it down to just a patch for a QNX port? and leave the
> rest for another day.

I can certainly leave the rest for another day, the rest being only the
debugging change - the headers need something done to them, and flagging them
out for QNX seems pointless when they are redundant. They should just be
removed, no?

This patch is a showstopper for QNX in that you cannot compile on QNX without
it.

The debugging change is nice under both QNX and SCO - QNX is completely
unable to do a stack backtrace from a caught signal, and SCO skips up the
stack to the innermost call.

> rob

Cheers,

Ben.

--
Ben Laurie Phone: +44 (181) 994 6435
Freelance Consultant Fax: +44 (181) 994 6472
and Technical Director Email: ben@algroup.co.uk
A.L. Digital Ltd,
London, England.

> -1 for a release on Sunday, as hyperreal will be down then. 8-(
>
> Actaully, I think that we should not release 1.0 without the 30_svr4
> patch. We will probably have binaries for the affected systems, which
> will be built using a patched version of the source. It would be daft
> to release source that couldn't be used to compile binaries for some
> systems.

Okey dokey.

Can someone work out a timetable for 1.0 then. Unless someone does it
we'll be sitting around for some time to come.


30_srv4 is simple enough to drop in, and those who can test it will
already have done so by now I guess.


Network problems delayed my mail until after Brian mentioned the power
outage. The networks are pretty unreliable these days. Anyone else
noticing this?

It's nearly done. I'm hoping to copy it back to hyperreal very soon;

That would be nice, but I'd prefer for it not to replace the existing
docs until after we've had a chance to give them a once over... a docs-new
directory, or some such, might be the best way to do this. (I believe
Andrew has concurred with me on this...).

rst

[. I'm trying to look them over now from your site, but the net connection
is making that painful ]

> >
> > David's svr4 patch is a showstopper for some OSs, like newer UnixWare, so
> > I'd suggest including that, anyway.
> >
> > +1 with that stipulation.
>
> The same applies to the QNX patch.

If it's a showstopper, then the comments to describe it fail to convey that...

*********************************************************************
Comments: This patch also removes some redundant headers (not gratuitously,
^^^^^^^^^^^^^^^^^
they had to go on QNX anyway, and were already included in some other
local header). It also adds a debugging convenience; SIGSEGV and SIGBUS
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
are not caught when in debug mode (-X flag). This makes running under
some debuggers better.
*********************************************************************


Those statements don't suggest any kind of urgency.
I suppose the "This patch also" is the key phrase there.

Can you strip it down to just a patch for a QNX port? and leave the
rest for another day.

rob

Rob:
> Does anyone consider the bugs being fixed by patches in /for_Apache_0.8.15
> to be showstoppers?
>
> I don't, and am happy to release 0.8.15 as 1.0 in the very near future,
> perhaps at the weekend. We lost a couple of days on the Oct 20th timetable,
> so how about Sunday 22nd?
>
> 1.0 is stable. It has minor bugs, but what server doesn't?.
>
> Once we have a 1.0 available, we can go to town on all the features that
> have so far been on hold, and keep 1.0 as a "use this if you're worried"
> fallback, which is what 0.6.5 is doing now.
>
>
> So I vote +1 on a release of 0.8.15 under the version
> number 1.0 this Sunday...

> vote or veto please.


The file/virtual problem isn't a 'show stopper' but it'll necessitate 1.0.1
almost immediately to fix the oversight. You wanna look stupid? Remember
ideally we wouldn't release another 'stable' server for quite a while.

-1

Ay

-1 for a release on Sunday, as hyperreal will be down then. 8-(

Actaully, I think that we should not release 1.0 without the 30_svr4
patch. We will probably have binaries for the affected systems, which
will be built using a patched version of the source. It would be daft
to release source that couldn't be used to compile binaries for some
systems.

David.

> Network problems delayed my mail until after Brian mentioned the power
> outage. The networks are pretty unreliable these days. Anyone else
> noticing this?

Hi Rob, welcome to the internet. You're new to all this I take it.

Ay.

>If we're going to have a revised set of docs, I'd also prefer
>to wait until those have had a group review, to chase out what
>typographical errors may have crept in... there are few things that
>look less professional than doc bugs (say, the omission of a crucial
>"not", which I can say from experience is all too easy to commit), and
>avoiding that is worth some time and effort.

I've put a snap-shot of the latest docs on
<URL:http://www.ast.cam.ac.uk/~drtr/apache/>

(The only differences are in the 'Server Documentation' directory.)

It's nearly done. I'm hoping to copy it back to hyperreal very soon;

I've held back slightly because of the few incompatibility bugs that
I've turned up; currently I've documented the (my) desired behaviour, rather
than the actual 0.8.15 behaviour.

David.

>> It's nearly done. I'm hoping to copy it back to hyperreal very soon;
>
>That would be nice, but I'd prefer for it not to replace the existing
>docs until after we've had a chance to give them a once over... a docs-new
>directory, or some such, might be the best way to do this. (I believe
>Andrew has concurred with me on this...).

Sure.

>[. I'm trying to look them over now from your site, but the net connection
> is making that painful ]

It's even more painful coming the other way and trying to work interactively
on hyperreal...

I guess I could try to put up the snap-shot...

David.