Mailing List Archive

+1 add the 2 showstopper patches, create 1.0, install, release following day

-1. I don't believe there's general agreement about which of the current
patches *are* the two showstoppers --- the svr4 patch is the only one of
the current batch which seems that way to me.

And why the rush? Another day more or less won't make much of a difference,
except if some hastily tossed-in, half-tested patch introduces a nasty bug
in 1.0 which *wasn't* present in any beta --- that could hurt us badly, and
it's worth taking a little extra time to avoid.

If we're going to be doing binary releases anyway, those will probably take
a few days to throw together; at the *very* least, we should be running the
release candidate ourselves to try and make sure there isn't anything
unexpectedly nasty about it. If we can put it up as 0.8.16 as well, and get
at least a little public testing, so much the better. But releasing 1.0
tomorrow is *way* too hasty.

rst

At 03:47 PM 10/24/95 -0400, you wrote:
>Rob Hartill liltingly intones:
>>
>>
>> +1 add the 2 showstopper patches, create 1.0, install, release following day
>>
>>
>+1 also, same patch stipulation, seems stable on a bunch 'o platforms here.
>

+1... although I'm having a small bit of problem with Linux ELF. But I don't
think it's Apache... rather my setup. I'm gonna have a clean machine to
work off of this weekend.... I'll know more then.

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

> +1 add the 2 showstopper patches, create 1.0, install, release following day

> at least a little public testing, so much the better. But releasing 1.0
> tomorrow is *way* too hasty.

"tomorrow" wasn't the idea, I was suggesting we release it a day after
we had the chance to install it ourselves.. whenever that might be.

As for the showstoppers, the 'srv' patch is okay by me. The
qnx fix I could live without or accept more easily if it were
stripped down to the bare minimum. Ben calls it a showstopper
bug, so we either fix it or fix Ben ;-)

How about this...

Aim to patch 0.8.15 tomorrow evening, with or without a stripped
down qnx patch. That gives Ben just a few hours to replace the
patch with something that's acceptable, but that's life. If anyone
vetos the qnx patch, it's history.

Upload "1.0" to hyperreal by wednesday lunchtime (US)
Create binaries and upload them ASAP

Move things into place on Thursday afternoon (US)


I guess some people aren't going to like this, if so, propose something
else, please.

rob

Oh gawd, I don't know what day it is.

> How about this...
>
> Aim to patch 0.8.15 tomorrow evening, with or without a stripped
^^^^^^^^
wednesday

> down qnx patch. That gives Ben just a few hours to replace the
> patch with something that's acceptable, but that's life. If anyone
> vetos the qnx patch, it's history.
>
> Upload "1.0" to hyperreal by wednesday lunchtime (US)
^^^^^^^^^
thursday

> Create binaries and upload them ASAP
>
> Move things into place on Thursday afternoon (US)
^^^^^^^^
friday

On Tue, 24 Oct 1995 16:16:13 -0400 you wrote:

>> +1 add the 2 showstopper patches, create 1.0, install, release following day
>
>-1. I don't believe there's general agreement about which of the current
>patches *are* the two showstoppers --- the svr4 patch is the only one of
>the current batch which seems that way to me.
>
>And why the rush? Another day more or less won't make much of a difference,
>except if some hastily tossed-in, half-tested patch introduces a nasty bug
>in 1.0 which *wasn't* present in any beta --- that could hurt us badly, and
>it's worth taking a little extra time to avoid.
>
>If we're going to be doing binary releases anyway, those will probably take
>a few days to throw together; at the *very* least, we should be running the
>release candidate ourselves to try and make sure there isn't anything
>unexpectedly nasty about it. If we can put it up as 0.8.16 as well, and get
>at least a little public testing, so much the better. But releasing 1.0
>tomorrow is *way* too hasty.

-1 on such a quick release. I also think we should do a 0.8.16,
internal to developers only, and put a freeze on all patches except to
fix something broken from 0.8.15 to 0.8.16. Let 0.8.16 live for 3-5
days, while we get binaries collected, than then relabel it 1.0


Garey Smiley
SoftLink Services
garey@slink.com
http://www.slink.com/
(216)848-1312 FAX/Data(216)699-4474