Mailing List Archive: Votes on current patches

Votes on current patches

Oct 11, 1995, 3:42 PM

Post #1 of 15 (590 views)

Here are my votes on the current patches. I hope that if any new ones
appear, the vote deadline will be pushed back long enough to give the
rest of us a decent opportunity for review.

Incidentally, the patch to add parens around the first subexpression
in this if-statement from run_method:

if (result != DECLINED && (!run_all || result != OK))

didn't seem to be there. Since people report that it does fix a
problem on some systems, it has my +1 if it ever shows up.

[. All +1'ed patches have been applied and checked; this involved
using Ben's corrected version of 04a ]

+1 01_http_config.0.8.14.patch
+1 02_DBMGroupCoreFix.0.8.14.patch
-1 03_XBITHACK_restrict.0.8.14.patch --- withdrawn [no patch present]
+1 04a_ExtraPath.0.8.14.patch [after Ben's correction]
+1 05_NoKill.0.8.14.patch
+1 06_SCODocFix.0.8.14.patch
+1 07_SocketMemLeak.0.8.14.patch
+1 08_license.0.8.14.patch
+1 09_HP_comment.0.8.14.patch
+1 10_mutual-failure.0.8.14.patch
+1 11_fd_removal.0.8.14.patch
+1 12_del_max_security.0.8.14.patch
+1 13_error_fd.0.8.14.patch
+1 14_rlimit.0.8.14.patch
+1 15_urlchars.0.8.14.patch
+1 16_alias.0.8.14.patch
-1 17_const.0.8.14.patch --- As I've said before, I feel cleanups of this
sort are inappropriate at this point in the release cycle.
+1 18_geteuid.apache_0.8.14.patch
+1 19_redir.0.8.14.patch
+1 20_score.0.8.14.patch
+1 21.escape.0.8.14.patch
+1 22.spawn.0.8.14.patch
-1 23.mmap.0.8.14.patch --- Again, I don't feel this sort of thing is
appropriate at this point in the release cycle; it changes a
whole lot of code, and poses a substantial risk of causing more
problems than it cures.
+1 24_imap.0.8.14.patch --- Two small changes, both fixing clear bugs.
-1 25_startserver.0.8.14.patch --- See Andrew's comments.

Re: Votes on current patches [ In reply to ]

brian at organic

Oct 12, 1995, 2:37 AM

Post #2 of 15 (591 views)

I ditto rst's +1 patches - applied and checked on BSDI 2.0 and gcc. It's
running on Hyperreal right now. I can also confirm that that set of patches
compiles under Irix 5.3 with the SGI compiler (my installation of gcc is
broken) and on Solaris with the CCS cc and gcc.

(Have I redeemed myself for being away so long yet? :)

I strongly feel there's no need to call this 0.8.15. Let's make it 1.0,
circle it around a little bit for a few days, and then make an
announcement.

Brian

On Wed, 11 Oct 1995, Robert S. Thau wrote:
> Here are my votes on the current patches. I hope that if any new ones
> appear, the vote deadline will be pushed back long enough to give the
> rest of us a decent opportunity for review.
>
> [. All +1'ed patches have been applied and checked; this involved
> using Ben's corrected version of 04a ]
>
> +1 01_http_config.0.8.14.patch
> +1 02_DBMGroupCoreFix.0.8.14.patch
> -1 03_XBITHACK_restrict.0.8.14.patch --- withdrawn [no patch present]
> +1 04a_ExtraPath.0.8.14.patch [after Ben's correction]
> +1 05_NoKill.0.8.14.patch
> +1 06_SCODocFix.0.8.14.patch
> +1 07_SocketMemLeak.0.8.14.patch
> +1 08_license.0.8.14.patch
> +1 09_HP_comment.0.8.14.patch
> +1 10_mutual-failure.0.8.14.patch
> +1 11_fd_removal.0.8.14.patch
> +1 12_del_max_security.0.8.14.patch
> +1 13_error_fd.0.8.14.patch
> +1 14_rlimit.0.8.14.patch
> +1 15_urlchars.0.8.14.patch
> +1 16_alias.0.8.14.patch
> -1 17_const.0.8.14.patch --- As I've said before, I feel cleanups of this
> sort are inappropriate at this point in the release cycle.
> +1 18_geteuid.apache_0.8.14.patch
> +1 19_redir.0.8.14.patch
> +1 20_score.0.8.14.patch
> +1 21.escape.0.8.14.patch
> +1 22.spawn.0.8.14.patch
> -1 23.mmap.0.8.14.patch --- Again, I don't feel this sort of thing is
> appropriate at this point in the release cycle; it changes a
> whole lot of code, and poses a substantial risk of causing more
> problems than it cures.
> +1 24_imap.0.8.14.patch --- Two small changes, both fixing clear bugs.
> -1 25_startserver.0.8.14.patch --- See Andrew's comments.
>
>
>

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/

Re: Votes on current patches [ In reply to ]

randy at zyzzyva

Oct 12, 1995, 5:57 AM

Post #3 of 15 (592 views)

I'll mirror my votes from RST's. All patches applied and tested on
SunOS 4.1.3 and NetBSD-current. The server is installed and running
on all of my webservers.

Regarding 04a: I agree that this could be an interesting feature.
Perhaps we can implement it in a way that will not cause problems for
robots as well...

> +1 01_http_config.0.8.14.patch
> +1 02_DBMGroupCoreFix.0.8.14.patch
> -1 03_XBITHACK_restrict.0.8.14.patch --- withdrawn [no patch present]
> +1 04a_ExtraPath.0.8.14.patch [after Ben's correction]
> +1 05_NoKill.0.8.14.patch
> +1 06_SCODocFix.0.8.14.patch
> +1 07_SocketMemLeak.0.8.14.patch
> +1 08_license.0.8.14.patch
> +1 09_HP_comment.0.8.14.patch
> +1 10_mutual-failure.0.8.14.patch
> +1 11_fd_removal.0.8.14.patch
> +1 12_del_max_security.0.8.14.patch
> +1 13_error_fd.0.8.14.patch
> +1 14_rlimit.0.8.14.patch
> +1 15_urlchars.0.8.14.patch
> +1 16_alias.0.8.14.patch
> -1 17_const.0.8.14.patch --- As I've said before, I feel cleanups of this
> sort are inappropriate at this point in the release cycle.
> +1 18_geteuid.apache_0.8.14.patch
> +1 19_redir.0.8.14.patch
> +1 20_score.0.8.14.patch
> +1 21.escape.0.8.14.patch
> +1 22.spawn.0.8.14.patch
> -1 23.mmap.0.8.14.patch --- Again, I don't feel this sort of thing is
> appropriate at this point in the release cycle; it changes a
> whole lot of code, and poses a substantial risk of causing more
> problems than it cures.
> +1 24_imap.0.8.14.patch --- Two small changes, both fixing clear bugs.
> -1 25_startserver.0.8.14.patch --- See Andrew's comments.

Re: Votes on current patches [ In reply to ]

Oct 12, 1995, 7:29 AM

Post #4 of 15 (590 views)

I strongly feel there's no need to call this 0.8.15. Let's make it 1.0,
circle it around a little bit for a few days, and then make an
announcement.

I don't like the idea --- if there are last-minute problems with it, it
would be awkward to call the fixed version 1.1. On the other hand, if
there aren't any, then it's no trouble at all to change one line in
httpd.h for the announcement. Best to leave the version number at
0.8.15 for what everyone agrees to be a necessary try-out...

rst

Re: Votes on current patches [ In reply to ]

Oct 12, 1995, 9:14 AM

Post #5 of 15 (590 views)

At 09:34 AM 10/12/95 MDT, you wrote:
>
>> I strongly feel there's no need to call this 0.8.15. Let's make it 1.0,
>> circle it around a little bit for a few days, and then make an
>> announcement.
>>
>> I don't like the idea --- if there are last-minute problems with it, it
>> would be awkward to call the fixed version 1.1. On the other hand, if
>> there aren't any, then it's no trouble at all to change one line in
>> httpd.h for the announcement. Best to leave the version number at
>> 0.8.15 for what everyone agrees to be a necessary try-out...
>
>I though we were aiming for a Oct 20th release of 1.0
>
>

I'm not sure we should call it 1.0 either.... at least not right off the bat.
We should built 15. If there are no problems as it goes around then
we'll call it 1.0. After 1.0 is released we can't do as many releases
as we have in the past.... we'll hit 10.0 in a year... Each release after
this should be very carefully monitored, so let's not jump in, if we don't
have to.

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

Re: Votes on current patches [ In reply to ]

Oct 12, 1995, 9:34 AM

Post #6 of 15 (589 views)

> I strongly feel there's no need to call this 0.8.15. Let's make it 1.0,
> circle it around a little bit for a few days, and then make an
> announcement.
>
> I don't like the idea --- if there are last-minute problems with it, it
> would be awkward to call the fixed version 1.1. On the other hand, if
> there aren't any, then it's no trouble at all to change one line in
> httpd.h for the announcement. Best to leave the version number at
> 0.8.15 for what everyone agrees to be a necessary try-out...

I though we were aiming for a Oct 20th release of 1.0

Re: Votes on current patches [ In reply to ]

Oct 12, 1995, 10:40 AM

Post #7 of 15 (588 views)

> I'm not sure we should call it 1.0 either.... at least not right off the bat.
> We should built 15. If there are no problems as it goes around then
> we'll call it 1.0.

As it "goes around" where?

Are you suggesting we release something called 0.8.15, wait for a showstopper
bug them rename it 1.0?

I renamed my verions "1.0candidate", makes me feel much better ;-)

After "1.0.almost" is built, we'll have a week to test it on all the
platforms we know have access to.

> After 1.0 is released we can't do as many releases
> as we have in the past....

says who? :-)

> we'll hit 10.0 in a year...

No, we'd have 1.8.14

> Each release after this should be very carefully monitored,

that implies they aren't now, which isn't the case.

> so let's not jump in, if we don't have to.

jump jump jump! this is not rocket science.

rob

Re: Votes on current patches [ In reply to ]

Oct 12, 1995, 10:41 AM

Post #8 of 15 (593 views)

At 10:40 AM 10/12/95 MDT, you wrote:
>
>> I'm not sure we should call it 1.0 either.... at least not right off the bat.
>> We should built 15. If there are no problems as it goes around then
>> we'll call it 1.0.
>
>As it "goes around" where?

Before it's released.

>
>Are you suggesting we release something called 0.8.15, wait for a showstopper
>bug them rename it 1.0?
>
>I renamed my verions "1.0candidate", makes me feel much better ;-)
>
>After "1.0.almost" is built, we'll have a week to test it on all the
>platforms we know have access to.

Same things... I wouldn't just take 0.8.14, patch it ((((20)))) different
patches, and release it as 1.0. I would feel better if xxxxx [ whatever
you wanna call it ] is built.... We don't see any major problems, everyone
is happy with it for the mostpart... and then release the sucker as 1.0.

>
>> After 1.0 is released we can't do as many releases
>> as we have in the past....
>
>says who? :-)

ME! :) Noway... we're releaseing a new release every week, that's
crazy, and unstable software. There is obsolutly no way we can release
patches like that, ESPECIALLY since we're not going to allow
enhancements in to the code. Something is gonna break something else
along the line.

>> Each release after this should be very carefully monitored,
>
>that implies they aren't now, which isn't the case.

We're also not doing anything new. Just patching up things.

>
>> so let's not jump in, if we don't have to.
>
>jump jump jump! this is not rocket science.

You sure? I thought we were hyperreal is running on one of those juices
it's famous for?

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

Re: Votes on current patches [ In reply to ]

Oct 12, 1995, 5:16 PM

Post #9 of 15 (590 views)

> I though we were aiming for a Oct 20th release of 1.0

That was my understanding, although we've not taken a vote on it.

+1 we aim for Oct 20th.

Ay.

Re: Votes on current patches [ In reply to ]

fielding at avron

Oct 12, 1995, 6:25 PM

Post #10 of 15 (590 views)

Looks like there are already plenty of votes, so I'll just continue
my other work and give the 0.8.15 build version (or 1.0, whatever)
a thorough testing.

....Roy

Re: Votes on current patches [ In reply to ]

randy at zyzzyva

Oct 12, 1995, 6:58 PM

Post #11 of 15 (592 views)

> > I though we were aiming for a Oct 20th release of 1.0
>
> That was my understanding, although we've not taken a vote on it.
>
> +1 we aim for Oct 20th.
>
> Ay.

Mine as well... It's coming....

October 20 - 1.0

+1

Re: votes on current patches [ In reply to ]

randy at zyzzyva

Nov 19, 1995, 12:12 PM

Post #12 of 15 (591 views)

Brian sez:
> +1 40_tz.0.8.16.patch
> However, this is only set if "TZ" is an environment variable already
> - isn't there a way to get it from the system directly?

Hmm. Good point. I check and *none* of the machines I run servers on
set TZ. I've uploaded a patch (40a_tz.0.8.16.patch) that will get this
value from the system. The patch works on both SunOS4.1.3 and NetBSD1.1.
The value is CST for these machines. The only machine I found in my
stable that sets this are the HPsUX machines. However they set CST6CDT.
What do we expect this to be? I have not checked to see what this code
will pull from the tz struct.

+0 40_tz.0.8.16.patch
+1 40a_tz.0.8.16.patch

+1 41_getparents.0.8.16.patch
+1 42_cert.no2slash.0.8.16.patch
0 43_slashredir.0.8.16.patch
+1 43a_slashredir.0.8.16.patch
+1 44_ident.0.8.16.patch (conditional)
This patch creates warning on BSDI_1.1, SunOS_4.1.3, and NetBSD_1.1
from the following declarations. Declaring this to be struct sockaddr
works on all of these platforms. My hunch is that this will cause
warnings on more machines than not. A quick look at HPsUX shows that
that parameter for getsockname() is a void *. The condition is that
this get cleared by whomever rolls the release. I would be happy to
volunteer to do this if no one else fights me for it.

+1 45_dbm_groups.0.8.16.patch
+1 46.dbmmanage_group.0.8.16.patch
> *IF* the release builder can modify the "usage" documentation to mention
> this enhancement.
Agreed

+1 47.allow.0.8.16.patch
+1 48.log-ssi.0.8.16.patch
+1 50.imagemap.0.8.16.patch
+1 51.requires.0.8.16.patch
+1 52.extralibs.0.8.16.patch
+1 53.README_enhancement.0.8.16.patch

There was also a 51.redirect* in that directory yesterday. What's the
story?

Re: votes on current patches [ In reply to ]

randy at zyzzyva

Nov 19, 1995, 12:34 PM

Post #13 of 15 (591 views)

Ooops... Reference to http_main.c included below.

> +1 44_ident.0.8.16.patch (conditional)
> This patch creates warning on BSDI_1.1, SunOS_4.1.3, and NetBSD_1.1
> from the following declarations. Declaring this to be struct sockaddr
> works on all of these platforms. My hunch is that this will cause
> warnings on more machines than not. A quick look at HPsUX shows that
> that parameter for getsockname() is a void *. The condition is that
> this get cleared by whomever rolls the release. I would be happy to
> volunteer to do this if no one else fights me for it.

#if defined(NEXT) || defined(LINUX) || defined(SOLARIS2)
struct sockaddr sa_server;
struct sockaddr sa_client;
#else
struct sockaddr_in sa_server,sa_client;
#endif

Re: votes on current patches [ In reply to ]

Nov 19, 1995, 2:57 PM

Post #14 of 15 (591 views)

>
> Brian sez:
> > +1 40_tz.0.8.16.patch
> > However, this is only set if "TZ" is an environment variable already
> > - isn't there a way to get it from the system directly?
>
> Hmm. Good point. I check and *none* of the machines I run servers on
> set TZ. I've uploaded a patch (40a_tz.0.8.16.patch) that will get this
> value from the system. The patch works on both SunOS4.1.3 and NetBSD1.1.
> The value is CST for these machines. The only machine I found in my
> stable that sets this are the HPsUX machines.

SCO does, GMT0BST in my case. Probably wrong though (doesn't specify the
changeover).

> However they set CST6CDT.
> What do we expect this to be? I have not checked to see what this code
> will pull from the tz struct.
>
> +0 40_tz.0.8.16.patch
> +1 40a_tz.0.8.16.patch
>
> +1 41_getparents.0.8.16.patch
> +1 42_cert.no2slash.0.8.16.patch
> 0 43_slashredir.0.8.16.patch
> +1 43a_slashredir.0.8.16.patch
> +1 44_ident.0.8.16.patch (conditional)
> This patch creates warning on BSDI_1.1, SunOS_4.1.3, and NetBSD_1.1
> from the following declarations. Declaring this to be struct sockaddr
> works on all of these platforms. My hunch is that this will cause
> warnings on more machines than not. A quick look at HPsUX shows that
> that parameter for getsockname() is a void *. The condition is that
> this get cleared by whomever rolls the release. I would be happy to
> volunteer to do this if no one else fights me for it.
>
> +1 45_dbm_groups.0.8.16.patch
> +1 46.dbmmanage_group.0.8.16.patch
> > *IF* the release builder can modify the "usage" documentation to mention
> > this enhancement.
> Agreed
>
> +1 47.allow.0.8.16.patch
> +1 48.log-ssi.0.8.16.patch
> +1 50.imagemap.0.8.16.patch
> +1 51.requires.0.8.16.patch
> +1 52.extralibs.0.8.16.patch
> +1 53.README_enhancement.0.8.16.patch
>
> There was also a 51.redirect* in that directory yesterday. What's the
> story?
>
>
>
>
>

--
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, URL: http://www.algroup.co.uk
London, England.

Re: votes on current patches [ In reply to ]

Nov 20, 1995, 3:40 PM

Post #15 of 15 (591 views)

Brian wrote:
>+1 42_cert.no2slash.0.8.16.patch
> Though I would *much* prefer to see a redirect to the "corrected"
> url rather than just serving the file.
>
>0 43_slashredir.0.8.16.patch
>+1 43a_slashredir.0.8.16.patch

So why not vote +1 on 43_slashredir which does generates a redirect to the
`corrected' url??

By contrast, 43a_slashredir does *not* produce a redirect. It simply fixes
the case where Apache was not even serving the file when an Alias was
involved.

David.