Re: Apache 1.3.31 RC Tarballs available
I'd like to announce and release the 11th. Are we still on track for this? Reports seem to have been good ... Kean
Re: Apache 1.3.31 RC Tarballs available
cross-posting to test-dev@, which is probably where we ought to discuss the gory details... Failed Test Stat Wstat Total Fail Failed List of Failed at this point the test part of the perl-framework is largely unmaintained. a few months ago I tried to stir up some interest in cleaning it up: http://marc.theaimsgroup.com/?l=apache-test-devm=107091289914815w=2 some of the issues there were fixed by myself and others, but a few remain outstanding. t/apache/contentlength.t 207 35.00% 2 6 10 14 16 18 20 t/modules/autoindex2.t 32 66.67% 1 3 these (or a subset thereof) have been failing at least since that email, but I just haven't gotten around to looking at them yet. (1 subtest UNEXPECTEDLY SUCCEEDED) IIRC this is from t/apache/include? I suspect this is due to some backported changes that were never updated in the test suite by andre or myself. I'll look at that this week unless andre beats me to it. t/apache/errordoc.t 2 51214 14 100.00% 1-14 I added that test recently and it passes for me on fedora. can you try $ t/TEST t/apache/errordoc.t -v and send that along (along with any relevant error_log messages). that all tests fail probably mean that it's not picking up on a required configuration thingy. t/modules/cgi.t464 8.70% 5-6 13-14 this just hangs for me, but there were some changes introduced recently that may account for this - without looking at the change log it something about STDERR IIRC. t/modules/expires.t924 4.35% 13 21 33 45 fails for me as well. it would be great to have the tests at 100% for current 1.3, 2.0, and 2.1. if we can get it to that point I volunteer to be the project watchdog who will pipe up if some commit causes the framework to suddenly fail (at least on the platform I run, currently fedora). but until we get to 100% the framework is kinda useless for RC testing as far as I'm concerned - known failures don't really mean much for this kind of thing. --Geoff
Re: Apache 1.3.31 RC Tarballs available
On May 9, 2004, at 4:18 PM, Geoffrey Young wrote: t/apache/errordoc.t 2 51214 14 100.00% 1-14 I added that test recently and it passes for me on fedora. can you try $ t/TEST t/apache/errordoc.t -v and send that along (along with any relevant error_log messages). that all tests fail probably mean that it's not picking up on a required configuration thingy. Same exact configuration I originally posted about, on same somewhat updated RH 8 box. tty says: t/TEST -httpd /tmp/ap/bin/httpd -apxs /tmp/ap/bin/apxs -v t/apache/errordoc.t [warning] setting ulimit to allow core files ulimit -c unlimited; /usr/bin/perl /home/sctemme/asf/perl-framework/t/TEST -httpd '/tmp/ap/bin/httpd' -apxs '/tmp/ap/bin/apxs' -v 't/apache/errordoc.t' [ notice] mod_test_ssl.c requires Apache version 2, skipping. [ notice] mod_test_pass_brigade.c requires Apache version 2, skipping. [ notice] mod_test_apr_uri.c requires Apache version 2, skipping. [ notice] mod_nntp_like.c requires Apache version 2, skipping. [ notice] mod_input_body_filter.c requires Apache version 2, skipping. [ notice] mod_client_add_filter.c requires Apache version 2, skipping. make: Nothing to be done for `all'. /tmp/ap/bin/httpd -d /home/sctemme/asf/perl-framework/t -f /home/sctemme/asf/perl-framework/t/conf/httpd.conf -D APACHE1 -D PERL_USEITHREADS using Apache/1.3.31 waiting 60 seconds for server to start: . waiting 60 seconds for server to start: ok (waited 3 secs) server eartha:8529 started t/apache/errordoc1..14 # Running under perl version 5.008 for linux # Current time local: Mon May 10 09:56:05 2004 # Current time GMT: Mon May 10 16:56:05 2004 # Using Test.pm version 1.23 Use of uninitialized value in concatenation (.) or string at /home/sctemme/asf/perl-framework/Apache-Test/lib/Apache/TestRequest.pm line 185. dubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 1-14 Failed 14/14 tests, 0.00% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- t/apache/errordoc.t2 51214 14 100.00% 1-14 Failed 1/1 test scripts, 0.00% okay. 14/14 subtests failed, 0.00% okay. [warning] server eartha:8529 shutdown [ error] error running tests (please examine t/logs/error_log) Access log: 127.0.0.1 - - [10/May/2004:09:56:05 -0700] GET /index.html HTTP/1.0 200 26 (Huh, only one entry for fourteen tests?) Error log: [Mon May 10 09:56:04 2004] [info] created shared memory segment #524292 [Mon May 10 09:56:04 2004] [notice] Apache/1.3.31 (Unix) configured -- resuming normal operations [Mon May 10 09:56:04 2004] [info] Server built: May 8 2004 07:49:35 [Mon May 10 09:56:04 2004] [notice] Accept mutex: sysvsem (Default: sysvsem) [Mon May 10 09:56:07 2004] [info] removed PID file /home/sctemme/asf/perl-framework/t/logs/httpd.pid (pid=11234) [Mon May 10 09:56:07 2004] [notice] caught SIGTERM, shutting down (not exotic at all) Rewrite log: 127.0.0.1 - - [10/May/2004:09:56:05 -0700] [eartha/sid#8093d54][rid#80c3edc/initial] (2) init rewrite engine with requested uri /index.html 127.0.0.1 - - [10/May/2004:09:56:05 -0700] [eartha/sid#8093d54][rid#80c3edc/initial] (1) pass through /index.html (that's that same request we saw in access_log) The single request for /index.html is the framework's ping to see if the server has started. It is not part of the errordoc tests, which suggests that these don't get to the server at all. t/modules/cgi.t464 8.70% 5-6 13-14 this just hangs for me, but there were some changes introduced recently that may account for this - without looking at the change log it something about STDERR IIRC. Yes, it hangs for the longest time and then continues. t/modules/expires.t924 4.35% 13 21 33 45 fails for me as well. it would be great to have the tests at 100% for current 1.3, 2.0, and 2.1. if we can get it to that point I volunteer to be the project watchdog who will pipe up if some commit causes the framework to suddenly fail (at least on the platform I run, currently fedora). but until we get to 100% the framework is kinda useless for RC testing as far as I'm concerned - known failures don't really mean much for this kind of thing. It has long been one of my desires to do an automated nightly build/test run on all three branches. As I get my lab set up here (which should happen in the next couple of weeks), I may be able to finally get that set up. When I was testing a product based on httpd 2.0, I would keep a list of known failures (we had some patches that the framework didn't deal with) on our internal Wiki, so I would know that a test had been failing and I wouldn't have to analyze every failure to death every time. That was stuff like OpenSSL would put the email field name of a certificate DN in uppercase, and RSA SSLC would put it in lowercase. Or was it
Re: Apache 1.3.31 RC Tarballs available
Use of uninitialized value in concatenation (.) or string at
/home/sctemme/asf/perl-framework/Apache-Test/lib/Apache/TestRequest.pm
The single request for /index.html is the framework's ping to see if
the server has started. It is not part of the errordoc tests, which
suggests that these don't get to the server at all.
yes. with 'use warnings FATAL = 'all'' the above error is causing the test
to die before it ever starts.
the problem seems to be in Apache::TestRequest::resolve_url(), but there is
no way for me to tell from here which part isn't being found properly.
are you running ssl? maybe putting this line
Apache::TestRequest::scheme('http');
just prior to the
Apache::TestRequest::module('error_document');
line in t/apache/errordoc.t would help. this appears to be the only
difference between errordoc.t and other modules that use a similar set of
directives to configure the test.
outside of that make sure that it's a fresh, pristine checkout, as if you
have some files hanging around it might collide with some of the
autogenerated stuff.
if neither of these work we'll have to poke around a bit in the internals,
but let's wait and see.
it would be great to have the tests at 100% for current 1.3, 2.0, and
2.1.
if we can get it to that point I volunteer to be the project watchdog
who
will pipe up if some commit causes the framework to suddenly fail (at
least
on the platform I run, currently fedora). but until we get to 100% the
framework is kinda useless for RC testing as far as I'm concerned -
known
failures don't really mean much for this kind of thing.
It has long been one of my desires to do an automated nightly
build/test run on all three branches. As I get my lab set up here
(which should happen in the next couple of weeks), I may be able to
finally get that set up.
cool, that would be great.
When I was testing a product based on httpd 2.0, I would keep a list of
known failures (we had some patches that the framework didn't deal
with) on our internal Wiki, so I would know that a test had been
failing and I wouldn't have to analyze every failure to death every
time.
yeah, that's the problem, wasting time trying to figure out whether the
failure is real or not, then somebody else doing the same thing. and it's
not an easy process, getting gritty with the code to make absolutely sure
whether the failure is in the codebase or the test expectations.
That was stuff like OpenSSL would put the email field name of a
certificate DN in uppercase, and RSA SSLC would put it in lowercase. Or
was it the other way around?
it would be great if we could capture that kind of thing in the test itself,
either in the actual test or in the framework (allow for case-insensitive
matches, for instance).
if you're willing (and can share internal knowledge publically, etc), I can
help integrate this particular issue into the framework. really, I'll do
whatever is required to get us at 100% - massive handholding if you know
what the issue is but can't quite grok the framework, verbose non-RTFM
explanations over irc or email, whatever...
Anyway, it would be great to get something like that going on a daily
basis. Kinda like an httpd project interpretation of Gump, like, Httpump.
agreed. well, let's see about what we can do to get the framework at 100%
and we can go from there. it's great to have someone else interested in all
of this :)
--Geoff
Re: Apache 1.3.31 RC Tarballs available
On May 9, 2004, at 4:18 PM, Geoffrey Young wrote: t/apache/errordoc.t 2 51214 14 100.00% 1-14 I added that test recently and it passes for me on fedora. can you try $ t/TEST t/apache/errordoc.t -v and send that along (along with any relevant error_log messages). that all tests fail probably mean that it's not picking up on a required configuration thingy. Same exact configuration I originally posted about, on same somewhat updated RH 8 box. tty says: t/TEST -httpd /tmp/ap/bin/httpd -apxs /tmp/ap/bin/apxs -v t/apache/errordoc.t [warning] setting ulimit to allow core files ulimit -c unlimited; /usr/bin/perl /home/sctemme/asf/perl-framework/t/TEST -httpd '/tmp/ap/bin/httpd' -apxs '/tmp/ap/bin/apxs' -v 't/apache/errordoc.t' [ notice] mod_test_ssl.c requires Apache version 2, skipping. [ notice] mod_test_pass_brigade.c requires Apache version 2, skipping. [ notice] mod_test_apr_uri.c requires Apache version 2, skipping. [ notice] mod_nntp_like.c requires Apache version 2, skipping. [ notice] mod_input_body_filter.c requires Apache version 2, skipping. [ notice] mod_client_add_filter.c requires Apache version 2, skipping. make: Nothing to be done for `all'. /tmp/ap/bin/httpd -d /home/sctemme/asf/perl-framework/t -f /home/sctemme/asf/perl-framework/t/conf/httpd.conf -D APACHE1 -D PERL_USEITHREADS using Apache/1.3.31 waiting 60 seconds for server to start: . waiting 60 seconds for server to start: ok (waited 3 secs) server eartha:8529 started t/apache/errordoc1..14 # Running under perl version 5.008 for linux # Current time local: Mon May 10 09:56:05 2004 # Current time GMT: Mon May 10 16:56:05 2004 # Using Test.pm version 1.23 Use of uninitialized value in concatenation (.) or string at /home/sctemme/asf/perl-framework/Apache-Test/lib/Apache/TestRequest.pm line 185. dubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 1-14 Failed 14/14 tests, 0.00% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- t/apache/errordoc.t2 51214 14 100.00% 1-14 Failed 1/1 test scripts, 0.00% okay. 14/14 subtests failed, 0.00% okay. [warning] server eartha:8529 shutdown [ error] error running tests (please examine t/logs/error_log) Access log: 127.0.0.1 - - [10/May/2004:09:56:05 -0700] GET /index.html HTTP/1.0 200 26 (Huh, only one entry for fourteen tests?) Error log: [Mon May 10 09:56:04 2004] [info] created shared memory segment #524292 [Mon May 10 09:56:04 2004] [notice] Apache/1.3.31 (Unix) configured -- resuming normal operations [Mon May 10 09:56:04 2004] [info] Server built: May 8 2004 07:49:35 [Mon May 10 09:56:04 2004] [notice] Accept mutex: sysvsem (Default: sysvsem) [Mon May 10 09:56:07 2004] [info] removed PID file /home/sctemme/asf/perl-framework/t/logs/httpd.pid (pid=11234) [Mon May 10 09:56:07 2004] [notice] caught SIGTERM, shutting down (not exotic at all) Rewrite log: 127.0.0.1 - - [10/May/2004:09:56:05 -0700] [eartha/sid#8093d54][rid#80c3edc/initial] (2) init rewrite engine with requested uri /index.html 127.0.0.1 - - [10/May/2004:09:56:05 -0700] [eartha/sid#8093d54][rid#80c3edc/initial] (1) pass through /index.html (that's that same request we saw in access_log) The single request for /index.html is the framework's ping to see if the server has started. It is not part of the errordoc tests, which suggests that these don't get to the server at all. t/modules/cgi.t464 8.70% 5-6 13-14 this just hangs for me, but there were some changes introduced recently that may account for this - without looking at the change log it something about STDERR IIRC. Yes, it hangs for the longest time and then continues. t/modules/expires.t924 4.35% 13 21 33 45 fails for me as well. it would be great to have the tests at 100% for current 1.3, 2.0, and 2.1. if we can get it to that point I volunteer to be the project watchdog who will pipe up if some commit causes the framework to suddenly fail (at least on the platform I run, currently fedora). but until we get to 100% the framework is kinda useless for RC testing as far as I'm concerned - known failures don't really mean much for this kind of thing. It has long been one of my desires to do an automated nightly build/test run on all three branches. As I get my lab set up here (which should happen in the next couple of weeks), I may be able to finally get that set up. When I was testing a product based on httpd 2.0, I would keep a list of known failures (we had some patches that the framework didn't deal with) on our internal Wiki, so I would know that a test had been failing and I wouldn't have to analyze every failure to death every time. That was stuff like OpenSSL would put the email field name of a certificate DN in uppercase, and RSA SSLC would put it in lowercase. Or
Re: Apache 1.3.31 RC Tarballs available
Use of uninitialized value in concatenation (.) or string at
/home/sctemme/asf/perl-framework/Apache-Test/lib/Apache/TestRequest.pm
The single request for /index.html is the framework's ping to see if
the server has started. It is not part of the errordoc tests, which
suggests that these don't get to the server at all.
yes. with 'use warnings FATAL = 'all'' the above error is causing the test
to die before it ever starts.
the problem seems to be in Apache::TestRequest::resolve_url(), but there is
no way for me to tell from here which part isn't being found properly.
are you running ssl? maybe putting this line
Apache::TestRequest::scheme('http');
just prior to the
Apache::TestRequest::module('error_document');
line in t/apache/errordoc.t would help. this appears to be the only
difference between errordoc.t and other modules that use a similar set of
directives to configure the test.
outside of that make sure that it's a fresh, pristine checkout, as if you
have some files hanging around it might collide with some of the
autogenerated stuff.
if neither of these work we'll have to poke around a bit in the internals,
but let's wait and see.
it would be great to have the tests at 100% for current 1.3, 2.0, and
2.1.
if we can get it to that point I volunteer to be the project watchdog
who
will pipe up if some commit causes the framework to suddenly fail (at
least
on the platform I run, currently fedora). but until we get to 100% the
framework is kinda useless for RC testing as far as I'm concerned -
known
failures don't really mean much for this kind of thing.
It has long been one of my desires to do an automated nightly
build/test run on all three branches. As I get my lab set up here
(which should happen in the next couple of weeks), I may be able to
finally get that set up.
cool, that would be great.
When I was testing a product based on httpd 2.0, I would keep a list of
known failures (we had some patches that the framework didn't deal
with) on our internal Wiki, so I would know that a test had been
failing and I wouldn't have to analyze every failure to death every
time.
yeah, that's the problem, wasting time trying to figure out whether the
failure is real or not, then somebody else doing the same thing. and it's
not an easy process, getting gritty with the code to make absolutely sure
whether the failure is in the codebase or the test expectations.
That was stuff like OpenSSL would put the email field name of a
certificate DN in uppercase, and RSA SSLC would put it in lowercase. Or
was it the other way around?
it would be great if we could capture that kind of thing in the test itself,
either in the actual test or in the framework (allow for case-insensitive
matches, for instance).
if you're willing (and can share internal knowledge publically, etc), I can
help integrate this particular issue into the framework. really, I'll do
whatever is required to get us at 100% - massive handholding if you know
what the issue is but can't quite grok the framework, verbose non-RTFM
explanations over irc or email, whatever...
Anyway, it would be great to get something like that going on a daily
basis. Kinda like an httpd project interpretation of Gump, like, Httpump.
agreed. well, let's see about what we can do to get the framework at 100%
and we can go from there. it's great to have someone else interested in all
of this :)
--Geoff
Re: Apache 1.3.31 RC Tarballs available
Jim Jagielski wrote: Via: http://httpd.apache.org/dev/dist/ Looks good on SCO OpenServer 5.0.7 and UnixWare 7.1.3. Kean
Re: Apache 1.3.31 RC Tarballs available
Looks good on gentoo as well. chuck On Sunday 09 May 2004 17:02, Kean Johnston wrote: Jim Jagielski wrote: Via: http://httpd.apache.org/dev/dist/ Looks good on SCO OpenServer 5.0.7 and UnixWare 7.1.3. Kean
Re: Apache 1.3.31 RC Tarballs available
cross-posting to test-dev@, which is probably where we ought to discuss the gory details... Failed Test Stat Wstat Total Fail Failed List of Failed at this point the test part of the perl-framework is largely unmaintained. a few months ago I tried to stir up some interest in cleaning it up: http://marc.theaimsgroup.com/?l=apache-test-devm=107091289914815w=2 some of the issues there were fixed by myself and others, but a few remain outstanding. t/apache/contentlength.t 207 35.00% 2 6 10 14 16 18 20 t/modules/autoindex2.t 32 66.67% 1 3 these (or a subset thereof) have been failing at least since that email, but I just haven't gotten around to looking at them yet. (1 subtest UNEXPECTEDLY SUCCEEDED) IIRC this is from t/apache/include? I suspect this is due to some backported changes that were never updated in the test suite by andre or myself. I'll look at that this week unless andre beats me to it. t/apache/errordoc.t 2 51214 14 100.00% 1-14 I added that test recently and it passes for me on fedora. can you try $ t/TEST t/apache/errordoc.t -v and send that along (along with any relevant error_log messages). that all tests fail probably mean that it's not picking up on a required configuration thingy. t/modules/cgi.t464 8.70% 5-6 13-14 this just hangs for me, but there were some changes introduced recently that may account for this - without looking at the change log it something about STDERR IIRC. t/modules/expires.t924 4.35% 13 21 33 45 fails for me as well. it would be great to have the tests at 100% for current 1.3, 2.0, and 2.1. if we can get it to that point I volunteer to be the project watchdog who will pipe up if some commit causes the framework to suddenly fail (at least on the platform I run, currently fedora). but until we get to 100% the framework is kinda useless for RC testing as far as I'm concerned - known failures don't really mean much for this kind of thing. --Geoff
Re: Apache 1.3.31 RC Tarballs available
Aaron Bannert wrote: I believe that a strict QA process actually hurts the quality of OSS projects like Apache. We have a gigantic pool of talented users who would love to give us a hand by testing our latest and greatest in every contorted way imaginable. But we're holding out on them. We're saying that we know better than they do. I don't think we do. Sure, we should be testing our code, but there's absolutely no way that we can be perfect. Closely held ivory-tower QA doesn't scale any better at the ASF than it does at a proprietary company. But the QA that comes out of widely distributed release-candidates _does_ scale. Why don't we let the teeming masses have their fill? I don't consider us a closely held ivory-tower QA and I would say that if anyone knows of a talented pool of users would would like to test RCs, then we should have a mechanism to use them. That was the intent for the current/stable-testers list, but we've never really used that as we should have. The problem is really 2 fold: 1. The tarballs were being mistakenly described as the official release. It's not released until we say so. I think it's our responsibility to ensure that people aren't mistakenly running pre-release s/w under the impression that it is release. 2. That when all goes well, and the RC tarballs are approved, they aren't changed at all... We are testing, really, the accuracy of the tarball itself. This add some complexity to the whole process. I've been thinking over changing the 1.3 release process and us actually tagging a tree as RC, creating actual 1.3.x-rc1 tarballs and people testing that, and having those very, very open, but having the actual *release* tarballs somewhat closed (again, to test the viability of the tarball, not the code). -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Apache 1.3.31 RC Tarballs available
I ran the perl-framework against the tarball on three platforms: On Darwin MonaLisa 7.3.0 Darwin Kernel Version 7.3.0: Fri Mar 5 14:22:55 PST 2004; root:xnu/xnu-517.3.15.obj~4/RELEASE_PPC Power Macintosh powerpc Failed Test Stat Wstat Total Fail Failed List of Failed --- t/apache/contentlength.t 207 35.00% 2 6 10 14 16 18 20 t/modules/autoindex2.t 32 66.67% 1 3 t/modules/expires.t924 4.35% 13 21 33 45 (1 subtest UNEXPECTEDLY SUCCEEDED), 12 tests and 14 subtests skipped. Failed 3/41 test scripts, 92.68% okay. 13/2175 subtests failed, 99.40% okay. On FreeBSD bagheera.shangrila.covalent.net 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #0: Mon Feb 23 20:45:55 GMT 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 Failed Test Stat Wstat Total Fail Failed List of Failed --- t/apache/contentlength.t 207 35.00% 2 6 10 14 16 18 20 t/modules/autoindex2.t 32 66.67% 1 3 t/modules/expires.t924 4.35% 13 21 33 45 t/modules/include.t771 1.30% 44 (1 subtest UNEXPECTEDLY SUCCEEDED), 12 tests and 14 subtests skipped. On Linux eartha 2.4.20-28.8 #1 Thu Dec 18 12:53:39 EST 2003 i686 i686 i386 GNU/Linux Failed Test Stat Wstat Total Fail Failed List of Failed --- t/apache/contentlength.t 207 35.00% 2 6 10 14 16 18 20 t/apache/errordoc.t 2 51214 14 100.00% 1-14 t/modules/autoindex2.t 32 66.67% 1 3 t/modules/cgi.t464 8.70% 5-6 13-14 t/modules/expires.t924 4.35% 13 21 33 45 t/modules/include.t25 640077 77 100.00% 1-77 12 tests skipped. Failed 6/41 test scripts, 85.37% okay. 108/2171 subtests failed, 95.03% okay. I don't know how many and which of these are known failures: I haven't the time today to run regressions against .29. S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: Apache 1.3.31 RC Tarballs available
On May 8, 2004, at 4:05 AM, Jim Jagielski wrote: I don't consider us a closely held ivory-tower QA and I would say that if anyone knows of a talented pool of users would would like to test RCs, then we should have a mechanism to use them. That was the intent for the current/stable-testers list, but we've never really used that as we should have. The problem is really 2 fold: 1. The tarballs were being mistakenly described as the official release. It's not released until we say so. I think it's our responsibility to ensure that people aren't mistakenly running pre-release s/w under the impression that it is release. I agree that it was mistakenly described as an official release, but I think we're confusing the idea of an official release with the concept of quality. It's difficult for us to state the quality of a release when our license[1] clearly says that we make no guarantees or warranties. Even if we say it's perfect, it's still a use at your own risk type of thing. 2. That when all goes well, and the RC tarballs are approved, they aren't changed at all... We are testing, really, the accuracy of the tarball itself. This add some complexity to the whole process. I don't think it needs to add to the complexity. I see us wanting to do simple sanity checking on the tarball, but even that lends itself to scalability. Assuming the tarballs are labeled as release candidates, people should be free to do whatever they want with them. If the signatures don't check out, they'll tell us. If it doesn't build, they'll tell us. If it works out for a few days we'll bless it. When it breaks we'll fix it and roll another tarball. I've been thinking over changing the 1.3 release process and us actually tagging a tree as RC, creating actual 1.3.x-rc1 tarballs and people testing that, and having those very, very open, but having the actual *release* tarballs somewhat closed (again, to test the viability of the tarball, not the code). I think this would be a step in the right direction. I still don't see why any stage in the release process should be closed, though. We don't make any guarantees about any of our code at any time, so as long as we make it totally clear when we want sanity checking (testing a release candidate) or when we want normal bug testing then I think we may see much greater participation by our users in the QA process, and as a result we will all have much higher quality code. -aaron [1] - Excerpt from http://www.apache.org/LICENSE.txt * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE.
Re: Apache 1.3.31 RC Tarballs available
Aaron Bannert wrote: I still don't see why any stage in the release process should be closed, though. We don't make any guarantees about any of our code at any time, Well, yes, you're right, we don't make any guarantees, but certainly our intent and desire is that we produce the best quality code we can and that the Apache name is trusted and associated with quality. So sometimes we need to act in ways to hopefully ensure that :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Apache 1.3.31 RC Tarballs available
The URL has been posted on slashdot :-( Joshua.
Re: Apache 1.3.31 RC Tarballs available
* Joshua Slive [EMAIL PROTECTED] wrote: The URL has been posted on slashdot :-( :-( I'd say, let's move it away. It's not released yet. period. nd -- print Just Another Perl Hacker; # André Malo, http://pub.perlig.de/ #
Re: Apache 1.3.31 RC Tarballs available
* Joshua Slive [EMAIL PROTECTED] |__ Fri, May 07, 2004 at 03:14:08PM -0400: The URL has been posted on slashdot :-( Oh no. It's not official yet. :-/ -- Chip Cuccio| [EMAIL PROTECTED] NORLUG VP and Sysadmin | http://norlug.org/~chipster/ Northfield Linux Users' Group | Northfield, Minnesota USA
Re: Apache 1.3.31 RC Tarballs available
On May 7, 2004, at 8:15 AM, Jim Jagielski wrote: Via: http://httpd.apache.org/dev/dist/ I'd like to announce and release the 11th. Except Slashdot beat you to the punch: http://apache.slashdot.org/. S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: Apache 1.3.31 RC Tarballs available
I have made the tarballs unavailable from the below URL. People should contact me directly to obtain the correct URL... Sander Temme wrote: --Apple-Mail-1-423850141 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On May 7, 2004, at 8:15 AM, Jim Jagielski wrote: Via: http://httpd.apache.org/dev/dist/ I'd like to announce and release the 11th. Except Slashdot beat you to the punch: http://apache.slashdot.org/. S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF --Apple-Mail-1-423850141 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGezCCAzQw ggKdoAMCAQICAwvmIjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMzEyMDYwODM5WhcNMDUwMzEyMDYwODM5WjCBhDEfMB0GA1UE AxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEfMB0GCSqGSIb3DQEJARYQc2FuZGVyQHRlbW1lLm5l dDEdMBsGCSqGSIb3DQEJARYOc2FuZGVyQG1hYy5jb20xITAfBgkqhkiG9w0BCQEWEnNjdGVtbWVA YXBhY2hlLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALDRNkTCskDD/q/7gGYW w8vdRiZ8aTIC8i+f5nCsFMF2o/tLC0oskhPzk0l5v8RxYKRa1DVJOUEW/RVoLbp0woyQnSBtNpjB XUHdSZ+9r+K3MdGLMDStdJbz6lW4ck4sJbJcfoZx7/ZhprFhYDUaS3v7mWZpCzV8uHwL1psJ+I/k nV3bksbE2FK9E6/TAFPh6af1aCKGSs+d7El/xhAFnPVlfHEaeOOdY+GieHYCgr6AVJlms8bjr7ad bbb30VoWOuzeX49aEBbWAsPy6pljEMvssD2AdJ2ZvcCxzPk4A5g6D0f0wQwpzPM7qsCiK1zMCLH4 pSzD6XmtXmBwnNpZvIECAwEAAaNRME8wPwYDVR0RBDgwNoEQc2FuZGVyQHRlbW1lLm5ldIEOc2Fu ZGVyQG1hYy5jb22BEnNjdGVtbWVAYXBhY2hlLm9yZzAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEB BAUAA4GBAIrTKvUSlPyS43Xm5fowg8vEU1yNctMIbl3CwBjhwn6UlVLh4iPy2gNW2ai2hDJv6K3E RraoZ6B2zOZ0oEVYw9on2oG3LVsORRTdji5SmwG7VhwuPxvM8+IFwlP7m3wsrSTTZ/YyPqNANR1I h16WNPKw6nsMbxfidJd/TpV7guYwMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRow GAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNl cyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZI hvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEz MDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Ia dr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+ K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1Ud EwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1Ro YXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRow GAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2as Zw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCU YsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9l TzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgML5iIwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMDQwNTA3MTkyMjIyWjAjBgkqhkiG9w0BCQQxFgQUZFQO5eXJ246GdqVInhw3fFf2ni8w eAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECAwvmIjB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBJc3N1aW5nIENBAgML5iIwDQYJKoZIhvcNAQEBBQAEggEACuTr81U5YRYrQq8RZru90GQTQGi5 HZCXyv5eYCRnlKQtTIXP1wyauPopSb6QByXmCPOIpngSxrKEXSczvHtP7h7AXd0y1TtLDGJCLeID vut23ovdoiXtSQmG0L3I3tDaBq/uVaLvEFqwRqmuVefLklxc+Om9W12OarJtncMk12lva20UhXuj 1pIDbnp10N25bocZcqvVs2Uf6Ri11sZDs04BkZiL22PONzFXSlMc5L1wk7V4lws80Bar7dDvyuAV TFGY60MKayXEK5VzrxlIYhnVVXa25A5W26RpqNYib4sN98V5/vXD1CGeOt0qxzZVS6ZufZMqFfjI ok78Zo5gdw== --Apple-Mail-1-423850141-- -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Apache 1.3.31 RC Tarballs available
Jim Jagielski wrote: I have made the tarballs unavailable from the below URL. People should contact me directly to obtain the correct URL... I'd like to give it a testing shoot for the cygwin platform on recent cygwin 1.5.x versions. Can you drop me an URL for it Jim please? Stipe mailto:[EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf, NRW, Germany phone: +49.211.74845.0 fax: +49.211.74845.299 mailto:[EMAIL PROTECTED] http://www.wapme-systems.de/ --- -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.2.2 (Cygwin) mIsEP6mcYwEEAMDnUiUwrbb+xwTFWN6TxF2+XZu7/alwJMeCwMBRvXtPZqfjpPhS OkBpU0F4TrVuugz1HINTSaJTYq10AzDQXp5NkyWgckqW79nPAWuOX0dicbJk+cN2 nM2TI4KaxUDe6u8hghNEnH/i2lXsUu9apnP/iixzV81VC2je3uc9hZpnAAYptEVT dGlwZSBUb2xqIChUZWNobm9sb2d5IENlbnRlciAmIFJlc2VhcmNoIExhYikgPHRv bGpAd2FwbWUtc3lzdGVtcy5kZT6ItAQTAQIAHgUCP6mcYwIbAwYLCQgHAwIDFQID AxYCAQIeAQIXgAAKCRABV0w1BqPYRuSqA/wPzsQxao2YePENCtgRTrO86U6zg3sl OcS6CJFI4FZP5h/xD3GRsNH1+MPSvZlomDdpFnr547DGz/Kq9MXuQwVvlVig5yWZ K5dtKp1r5YLhxJQBhfirZbRFFnYmf19f18J8OoS28tuFVftDl1AIwJS3HLyBTv6H g2HyLAEKQIp30Q== =aYCI -END PGP PUBLIC KEY BLOCK-
Re: Apache 1.3.31 RC Tarballs available
Why is it bad if people download the RC version and test it? Frankly, I really don't mind if slashdot or anyone else broadcasts that we have an RC tarball available. If anything it's a good thing. We don't make any guarantees about our code anyway, so whether or not we call it a GA release is just a courtesy to our users. Sheesh, this just seems like we're turning down would-be beta-testers! Please put the tarballs back up, and please ignore the press. -aaron On May 7, 2004, at 12:28 PM, Jim Jagielski wrote: I have made the tarballs unavailable from the below URL. People should contact me directly to obtain the correct URL... Sander Temme wrote: On May 7, 2004, at 8:15 AM, Jim Jagielski wrote: Via: http://httpd.apache.org/dev/dist/ I'd like to announce and release the 11th. Except Slashdot beat you to the punch: http://apache.slashdot.org/.
Re: Apache 1.3.31 RC Tarballs available
The trouble is that we need to perform *some* sort of quality control out there... The option is as soon as we have a tarball out, it's immediately released, in which case why even bother with a test or RC candidate. We need to, IMO, impose some sort of order and process on how we release s/w, and the simple fact that we have RC tarballs out there doesn't cut it. It's certainly a problem that we've had for some time, especially when you consider the times when releases are really security related... I would hate having some sort of private release mailing list where we can really test RC tarballs in a semi secure environment before they are released in general, but I can't see us simply saying our release procedure is we throw a tarball out there and 2-3 days after we do that we Announce it :) Aaron Bannert wrote: Why is it bad if people download the RC version and test it? Frankly, I really don't mind if slashdot or anyone else broadcasts that we have an RC tarball available. If anything it's a good thing. We don't make any guarantees about our code anyway, so whether or not we call it a GA release is just a courtesy to our users. Sheesh, this just seems like we're turning down would-be beta-testers! Please put the tarballs back up, and please ignore the press. -aaron On May 7, 2004, at 12:28 PM, Jim Jagielski wrote: I have made the tarballs unavailable from the below URL. People should contact me directly to obtain the correct URL... Sander Temme wrote: On May 7, 2004, at 8:15 AM, Jim Jagielski wrote: Via: http://httpd.apache.org/dev/dist/ I'd like to announce and release the 11th. Except Slashdot beat you to the punch: http://apache.slashdot.org/. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Apache 1.3.31 RC Tarballs available
* Aaron Bannert [EMAIL PROTECTED] wrote: Why is it bad if people download the RC version and test it? Frankly, I really don't mind if slashdot or anyone else broadcasts that we have an RC tarball available. Our traffic fee does anyway. RC stuff in /dev/dist/ is not mirrored. nd -- Winnetous Erbe: http://pub.perlig.de/books.html#apache2
Re: Apache 1.3.31 RC Tarballs available
On Fri, 7 May 2004, Aaron Bannert wrote: Why is it bad if people download the RC version and test it? Frankly, I really don't mind if slashdot or anyone else broadcasts that we have an RC tarball available. The problem was that they called it a release, not an RC. I added the header.html to that directory to try to make it clearer what people were downloading, but I think moving the tarball was appropriate given the chance of people trusting the slashdot info and believing this was a real release. Joshua.
Re: Apache 1.3.31 RC Tarballs available
I believe that a strict QA process actually hurts the quality of OSS projects like Apache. We have a gigantic pool of talented users who would love to give us a hand by testing our latest and greatest in every contorted way imaginable. But we're holding out on them. We're saying that we know better than they do. I don't think we do. Sure, we should be testing our code, but there's absolutely no way that we can be perfect. Closely held ivory-tower QA doesn't scale any better at the ASF than it does at a proprietary company. But the QA that comes out of widely distributed release-candidates _does_ scale. Why don't we let the teeming masses have their fill? -aaron On May 7, 2004, at 6:40 PM, Jim Jagielski wrote: The trouble is that we need to perform *some* sort of quality control out there... The option is as soon as we have a tarball out, it's immediately released, in which case why even bother with a test or RC candidate. We need to, IMO, impose some sort of order and process on how we release s/w, and the simple fact that we have RC tarballs out there doesn't cut it. It's certainly a problem that we've had for some time, especially when you consider the times when releases are really security related... I would hate having some sort of private release mailing list where we can really test RC tarballs in a semi secure environment before they are released in general, but I can't see us simply saying our release procedure is we throw a tarball out there and 2-3 days after we do that we Announce it :) Aaron Bannert wrote: Why is it bad if people download the RC version and test it? Frankly, I really don't mind if slashdot or anyone else broadcasts that we have an RC tarball available. If anything it's a good thing. We don't make any guarantees about our code anyway, so whether or not we call it a GA release is just a courtesy to our users. Sheesh, this just seems like we're turning down would-be beta-testers! Please put the tarballs back up, and please ignore the press. -aaron On May 7, 2004, at 12:28 PM, Jim Jagielski wrote: I have made the tarballs unavailable from the below URL. People should contact me directly to obtain the correct URL... Sander Temme wrote: On May 7, 2004, at 8:15 AM, Jim Jagielski wrote: Via: http://httpd.apache.org/dev/dist/ I'd like to announce and release the 11th. Except Slashdot beat you to the punch: http://apache.slashdot.org/. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Apache 1.3.31 RC Tarballs available
FWIW, we're currently only using half of our allocated bandwidth. If RC distributions become a bandwidth problem, we can think about mirroring then (wouldn't that be a great problem to have though?) -aaron On May 7, 2004, at 7:05 PM, André Malo wrote: * Aaron Bannert [EMAIL PROTECTED] wrote: Why is it bad if people download the RC version and test it? Frankly, I really don't mind if slashdot or anyone else broadcasts that we have an RC tarball available. Our traffic fee does anyway. RC stuff in /dev/dist/ is not mirrored. nd -- Winnetous Erbe: http://pub.perlig.de/books.html#apache2
Re: Apache 1.3.31 RC Tarballs available
Aaron Bannert wrote: I believe that a strict QA process actually hurts the quality of OSS projects like Apache. We have a gigantic pool of talented users who would love to give us a hand by testing I agree, but there is also a protocol to follow. If a user is interested in testing, they should join the dev or some testers list. Can users even post to the dev list if they are not subscribed (I dont know how the list is set up)? I think it was wrong of whoever it was that posted the info to slashdot to do so. I think the RM should be the one to make the announcements when and if they deem it necessary. I think people taking too much into their own hands can be detrimental to a project more than helpful. Why don't we just let Jim do his thing as RM and make the formal announcement when he is satisfied that the release is ready. If the dev team wants to solicit feedback for RC's then let the RM do it - its part of the job description. Kean
Re: Apache 1.3.31 RC Tarballs available
On May 7, 2004, at 7:26 PM, Aaron Bannert wrote: But we're holding out on them. We're saying that we know better than they do. I don't think we do. Sure, we should be In a way, we're holding out on them. However, I believe that a couple of days time to sanity check an RC is IMHO not a bad thing. The last thing we, as the Apache community, want is to have to retract a release after a couple thousand people find fault with it. I don't think many of us have the cycles for rigorous testing (I know I don't), and we certainly cannot account for every platform and configuration that our millions of users may be running the release in. This is where the 'many eyeballs' and 'all bugs are shallow' stuff comes in and yes, that is indeed one of the big strengths of the open source model. However, I still think staging a release so that a small number of informed volunteers can see that the tarball unzips, signatures match and that it builds and runs on their boxes, is a good thing. And everyone can participate: subscribing to [EMAIL PROTECTED] is open for everyone, and the same holds for current-testers@ and [EMAIL PROTECTED] S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
