Re: time for 1.3.40 and 2.2.7 ?
On 01/03/2008 12:21 AM, Ruediger Pluem wrote: But there was a problem with the _default_ setting for a virtual host. I am not sure so far if this is my config or if there is something else going wrong on Solaris 10. I will investigate tomorrow. This is a bug in Solaris 10. See also http://mail.opensolaris.org/pipermail/networking-discuss/2007-September/017120.html http://bugs.opensolaris.org/view_bug.do?bug_id=4944187 There might be even a patch for it, but I do not have sunsolve credentials at hand: http://sunsolve.sun.com/search/document.do?assetkey=1-1-4944187-1 Regards Rüdiger
Re: time for 1.3.40 and 2.2.7 ?
Ruediger Pluem schrieb: On 01/03/2008 12:21 AM, Ruediger Pluem wrote: But there was a problem with the _default_ setting for a virtual host. I am not sure so far if this is my config or if there is something else going wrong on Solaris 10. I will investigate tomorrow. This is a bug in Solaris 10. See also http://mail.opensolaris.org/pipermail/networking-discuss/2007-September/017120.html http://bugs.opensolaris.org/view_bug.do?bug_id=4944187 There might be even a patch for it, but I do not have sunsolve credentials at hand: http://sunsolve.sun.com/search/document.do?assetkey=1-1-4944187-1 Not there's no other info in this patch description document and sunsolve doesn't find a patch for it even with credentials. The bug has been last updated on December 18 this year, although it goes back to 2003. It looks like they are now producing a patch. The other links above already include the Sun suggested workarounds, either disable nscd (bad) or include DNS in /etc/nsswitch.conf. Regards Rüdiger Gutes Neues! Rainer
Re: time for 1.3.40 and 2.2.7 ?
Rainer Jung schrieb: been last updated on December 18 this year, although it goes back to this - last (it's already next year) :)
Re: time for 1.3.40 and 2.2.7 ?
Now that I am really back, I'd like to reboot the intent to TR all three. 2.2 has a current show-stopper however, with a veto upon the patch by Nick.
Re: time for 1.3.40 and 2.2.7 ?
On 01/02/2008 05:35 PM, Jim Jagielski wrote: Now that I am really back, I'd like to reboot the intent to TR all three. 2.2 has a current show-stopper however, with a veto upon the patch by Nick. You can solve this veto. Just vote for the vetoed patch plus for * mod_proxy_ftp: Introduce the ProxyFtpDirCharset directive, allowing the administrator to identify a default, or specific servers or paths which list their contents in other-than ISO-8859-1 charset (e.g. utf-8). [Ruediger Pluem] This makes Nick's veto void. Regards Rüdiger
Re: time for 1.3.40 and 2.2.7 ?
On Jan 2, 2008, at 11:49 AM, Ruediger Pluem wrote: On 01/02/2008 05:35 PM, Jim Jagielski wrote: Now that I am really back, I'd like to reboot the intent to TR all three. 2.2 has a current show-stopper however, with a veto upon the patch by Nick. You can solve this veto. Just vote for the vetoed patch plus for * mod_proxy_ftp: Introduce the ProxyFtpDirCharset directive, allowing the administrator to identify a default, or specific servers or paths which list their contents in other-than ISO-8859-1 charset (e.g. utf-8). [Ruediger Pluem] This makes Nick's veto void. Yes, I saw that, but I wanted to dig deeper and read his Email on why he didn't like it... Until that's resolved, the SS still exists (though with a caveat)
Re: time for 1.3.40 and 2.2.7 ?
On Wed, 2 Jan 2008 11:56:23 -0500 Jim Jagielski [EMAIL PROTECTED] wrote: Yes, I saw that, but I wanted to dig deeper and read his Email on why he didn't like it... Until that's resolved, the SS still exists (though with a caveat) In summary, I don't think that patch should spill outside mod_proxy_ftp. Putting it on the mod_proxy config, and hence involving changes to mod_proxy.h API and ap_mmn, seems like superfluous complexity/bloat. Especially when most mod_proxy users won't be requiring mod_proxy_ftp. But that's not a veto, just a -0. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: time for 1.3.40 and 2.2.7 ?
Jim Jagielski wrote: Yes, I saw that, but I wanted to dig deeper and read his Email on why he didn't like it... Well, he wanted a patch for a narrowly defined mod_proxy_ftp-specific directive context, but offered a patch to apply a server_rec, while Rudiger's patch is against the dir_rec which is much more appropriate. AIUI he questioned the need to change the general mod_proxy directive configuration structures for a mod_proxy_ftp specific directive. That said, I don't see the issue, think it could be useful to other proxy intermediaries, so let's just go with Rudiger's. Bill
Re: time for 1.3.40 and 2.2.7 ?
On Jan 2, 2008, at 12:25 PM, Nick Kew wrote: On Wed, 2 Jan 2008 11:56:23 -0500 Jim Jagielski [EMAIL PROTECTED] wrote: Yes, I saw that, but I wanted to dig deeper and read his Email on why he didn't like it... Until that's resolved, the SS still exists (though with a caveat) In summary, I don't think that patch should spill outside mod_proxy_ftp. Putting it on the mod_proxy config, and hence involving changes to mod_proxy.h API and ap_mmn, seems like superfluous complexity/bloat. Especially when most mod_proxy users won't be requiring mod_proxy_ftp. But that's not a veto, just a -0. And a valid point...
Re: time for 1.3.40 and 2.2.7 ?
On 01/02/2008 07:04 PM, Jim Jagielski wrote: On Jan 2, 2008, at 12:25 PM, Nick Kew wrote: On Wed, 2 Jan 2008 11:56:23 -0500 Jim Jagielski [EMAIL PROTECTED] wrote: Yes, I saw that, but I wanted to dig deeper and read his Email on why he didn't like it... Until that's resolved, the SS still exists (though with a caveat) In summary, I don't think that patch should spill outside mod_proxy_ftp. Putting it on the mod_proxy config, and hence involving changes to mod_proxy.h API and ap_mmn, seems like superfluous complexity/bloat. Especially when most mod_proxy users won't be requiring mod_proxy_ftp. But that's not a veto, just a -0. And a valid point... So far we have not put any configuration directives into mod_proxy_* even if they are specifc to a mod_proxy_* module (AllowCONNECT comes to mind). I do not say that this is correct, but I created my patch based on this and this seems to me a broader discussion that IMHO should not prevent us from releasing. Regards Rüdiger
Re: time for 1.3.40 and 2.2.7 ?
On 01/02/2008 05:35 PM, Jim Jagielski wrote: Now that I am really back, I'd like to reboot the intent to TR all three. 2.2 has a current show-stopper however, with a veto upon the patch by Nick. BTW: We have the same situation for 2.0.x. Only Nick did not put his veto in the STATUS file in this case. Regards Rüdiger
Re: time for 1.3.40 and 2.2.7 ?
FWIW, STATUS on the 2.x branches is cleaned up in anticipation of the TR (there are no open patches for 1.3, afaik). If you haven't already, I encourage everyone to 'svn up' and at least run some prelim tests before I do the actual TR. I've been working on getting my old Blade (Sol8) up and running (something's happened to it since I last booted it up) and test there (as well as on OS X and SUSE) before I tag. So it would be useful to get some prelim feedback that we are ready for a tag if others can test.
Re: time for 1.3.40 and 2.2.7 ?
On 01/02/2008 08:57 PM, Jim Jagielski wrote: FWIW, STATUS on the 2.x branches is cleaned up in anticipation of the TR (there are no open patches for 1.3, afaik). FWIW, the reason that caused Nick to veto on 2.2.x is still there on 2.0.x, so I guess it would be good if you could give it the missing vote and backport it. If you haven't already, I encourage everyone to 'svn up' and at least run some prelim tests before I do the actual TR. I've been working on getting my old Blade (Sol8) up and running (something's happened to it since I last booted it up) and test there (as well as on OS X and SUSE) before I tag. So it would be useful to get some prelim feedback that we are ready for a tag if others can test. First results for SuSE 10.2: 2.2.x: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/ssl/pr43738.t42 50.00% 2 4 7 tests and 18 subtests skipped. Failed 1/80 test scripts, 98.75% okay. 2/2841 subtests failed, 99.93% okay. But this is no regression. 2.0.x Failed Test Stat Wstat Total Fail Failed List of Failed --- t/ssl/pr43738.t42 50.00% 2 4 (1 subtest UNEXPECTEDLY SUCCEEDED), 15 tests and 25 subtests skipped. Failed 1/80 test scripts, 98.75% okay. 2/2816 subtests failed, 99.93% okay. But this is no regression. I try to get some more results in the next hour so stay tuned. Regards Rüdiger
Re: time for 1.3.40 and 2.2.7 ?
Ruediger Pluem wrote: First results for SuSE 10.2: 2.2.x: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/ssl/pr43738.t42 50.00% 2 4 7 tests and 18 subtests skipped. Failed 1/80 test scripts, 98.75% okay. 2/2841 subtests failed, 99.93% okay. But this is no regression. Agreed, but the patch is out there awaiting one more review (and Joe who wrote the patch hasn't chimed in, while I and Rudiger have). So it could be considered if one more reviews it. (I had cast this yesterday, but didn't commit it all in one go, because it would have made the status commit more confusing. Then I just forgot to add it.) Bill
Re: time for 1.3.40 and 2.2.7 ?
On 01/02/2008 08:57 PM, Jim Jagielski wrote: FWIW, STATUS on the 2.x branches is cleaned up in anticipation of the TR (there are no open patches for 1.3, afaik). If you haven't already, I encourage everyone to 'svn up' and at least run some prelim tests before I do the actual TR. I've been working on getting my old Blade (Sol8) up and running (something's happened to it since I last booted it up) and test there (as well as on OS X and SUSE) before I tag. So it would be useful to get some prelim feedback that we are ready for a tag if others can test. SuSE 10.2 32 Bit: All litmus tests passed for WebDAV. RedHat AS4 64 Bit: 2.0.x: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/ssl/pr43738.t42 50.00% 2 4 (1 subtest UNEXPECTEDLY SUCCEEDED), 16 tests and 25 subtests skipped. Failed 1/80 test scripts, 98.75% okay. 2/2790 subtests failed, 99.93% okay. No regression. 2.2.x: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/ssl/pr43738.t42 50.00% 2 4 9 tests and 18 subtests skipped. Failed 1/80 test scripts, 98.75% okay. 2/2807 subtests failed, 99.93% okay. No regression. Solaris 9: 2.2.x: My perl test kit is incomplete, but as far as I can tell no regressions could be found. Solaris 10: 2.2.x: My perl test kit is incomplete, but as far as I can tell no regressions could be found. But there was a problem with the _default_ setting for a virtual host. I am not sure so far if this is my config or if there is something else going wrong on Solaris 10. I will investigate tomorrow. My Solaris boxes are to0 slow to get test results for both 2.0.x and 2.2.x in time, but given the fact that the changes for 2.0.x are small compared to 2.2.x I only tested 2.2.x. Regards Rüdiger
Re: time for 1.3.40 and 2.2.7 ?
On Fri, 28 Dec 2007 19:56:27 +0100 Werner Baumann [EMAIL PROTECTED] wrote: Although I think, I explained it on http://issues.apache.org/bugzilla/show_bug.cgi?id=38034, here is a summary again. Thanks for the summary. It helps. My Proposal: Use the mod_dav-only patch as an intermediate solution, because it is urgent. This solution will not touch anything but mod_dav and can be removed without side effects as soon as a general solution is available. Take the time to consider how to change the interface of ap_meets_conditions (there might be more issues related to this) and include a clean general solution in 2.2.8. That makes sense to me, not least because Paritosh Shah's mod_dav-only patch is the easiest option to review. I'm satisfied with it on reading the code, so I'll give it a quick test-drive, and commit it if it doesn't break. Thank you for flagging this issue. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: time for 1.3.40 and 2.2.7 ?
Jim Jagielski wrote: Here's what I'd like to propose: o) We do another triple release: 1.3.40, 2.0.62 and 2.2.7 o) I tag and roll all 3 this Saturday (Dec 29th) o) We anticipate releasing/announcing all on Jan 2, 2008 It would be a great New Year's gift to the community :) Great news for all developers of WebDAV-clients: A five year old serious bug, that blocks the development of reliable WebDAV-clients (bug #16593 and #38034), is ignored once again, along with the working patches that are provided. Please remove mod_dav and mod_dav_fs from Apache before the release, so providers of WebDAV-services will have to look for a not that badly broken implementation, maybe an implementation that's cared about by it's developers. Werner
Re: time for 1.3.40 and 2.2.7 ?
On Fri, 28 Dec 2007 11:26:14 +0100 Werner Baumann [EMAIL PROTECTED] wrote: Jim Jagielski wrote: Here's what I'd like to propose: o) We do another triple release: 1.3.40, 2.0.62 and 2.2.7 o) I tag and roll all 3 this Saturday (Dec 29th) o) We anticipate releasing/announcing all on Jan 2, 2008 It would be a great New Year's gift to the community :) Great news for all developers of WebDAV-clients: A five year old serious bug, that blocks the development of reliable WebDAV-clients (bug #16593 and #38034), is ignored once again, along with the working patches that are provided. A quick look at the reports shows a lot of competing patches, and a lot of inconclusive discussion. So it doesn't look like a simple matter just to apply patches and close bug. If you're telling us it is a simple matter, perhaps you could post a summary here, as a startingpoint for reviewing what you propose. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: time for 1.3.40 and 2.2.7 ?
On Dec 27, 2007, at 5:01 PM, William A. Rowe, Jr. wrote: Guenter Knauf wrote: Hi Ruediger, Hm. I see no backport proposal for this in the STATUS file for 2.0.x. For formal reasons please add one. I would be +1 as well. sorry, but unfortunately that's not possible since 2.2.x and later do not have this file any longer - so there's no real backport proposal possible therefore I dont know how I should express the proposal ...? There's really no difference between STATUS, and on list discussion. The advantage to STATUS is reminding people to review over the long haul, the advantage to the list is collecting a quick three votes (when folks are paying attention). I disagree with Ruediger that any extra STATUS step is really needed. Well, for the RM, it's easier to go through STATUS and make sure all is set then sifting through the various Email lists :)
Re: time for 1.3.40 and 2.2.7 ?
The Apache Lounge Community tested a few days ago the 2.2.x code which should become 2.2.7 We noticed that Bill Rowe backed out the change which broke mod_fcgid and mod_fastcgi, so both mod_fcgid and mod_fastcgi work OK with the 2.2.x code. Unfortunately, mod_perl is still broken in the current code. Tom updated Bug 43534 with a new patch which fixes mod_perl in the current 2.2.x code: Bug 43534: http://issues.apache.org/bugzilla/show_bug.cgi?id=43534 new patch for Bug 43534: http://issues.apache.org/bugzilla/attachment.cgi?id=21264 but I don't know if you developers will pay any attention to it. Steffen http://www.apachelounge.com - Original Message - From: Jim Jagielski [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Thursday, 27 December, 2007 15:45 Subject: Re: time for 1.3.40 and 2.2.7 ? Here's what I'd like to propose: o) We do another triple release: 1.3.40, 2.0.62 and 2.2.7 o) I tag and roll all 3 this Saturday (Dec 29th) o) We anticipate releasing/announcing all on Jan 2, 2008 It would be a great New Year's gift to the community :)
Re: time for 1.3.40 and 2.2.7 ?
Jim Jagielski wrote: On Dec 27, 2007, at 5:01 PM, William A. Rowe, Jr. wrote: Guenter Knauf wrote: Hi Ruediger, Hm. I see no backport proposal for this in the STATUS file for 2.0.x. For formal reasons please add one. I would be +1 as well. sorry, but unfortunately that's not possible since 2.2.x and later do not have this file any longer - so there's no real backport proposal possible therefore I dont know how I should express the proposal ...? There's really no difference between STATUS, and on list discussion. The advantage to STATUS is reminding people to review over the long haul, the advantage to the list is collecting a quick three votes (when folks are paying attention). I disagree with Ruediger that any extra STATUS step is really needed. Well, for the RM, it's easier to go through STATUS and make sure all is set then sifting through the various Email lists :) Of course!!! The point I made was that STATUS is a great *tool* to ensure things are seen by your fellow committers, an RM and so forth. If something needs to happen, it better be in STATUS. You can do the same on-list, but don't holler at an RM when it's missed because you didn't follow things through to conclusion ;-) Bill
Re: time for 1.3.40 and 2.2.7 ?
Nick Kew wrote (concerning bug 38034): A quick look at the reports shows a lot of competing patches, and a lot of inconclusive discussion. So it doesn't look like a simple matter just to apply patches and close bug. If you're telling us it is a simple matter, perhaps you could post a summary here, as a startingpoint for reviewing what you propose. Don't try to get me flaming again. But I don't see a lot of competing patches. What I see is a lot of effort from outside apache to provide a patch for a five year old bug, with almost no response from apache developers, at least from no one, who would be able or willing to commit a patch. Although I think, I explained it on http://issues.apache.org/bugzilla/show_bug.cgi?id=38034, here is a summary again. But note: it is up to you, to look at the proposed patched, decide and do the real commit. And please don't try to start another *inconlusive discussion*, if you are not willing to commit a bug fix, that proves to work. The bug --- It's really two bugs: 1. mod_dav does not get the Etag and provide it to ap_meets_conditions. So ap_meets_conditions works with no or the wrong Etag, so decisions involving the Etag can't be correct. 2. ap_meets_conditions does not and cannot know, whether the resource exists. This knowledge is needed for decisions about If-Match: * and If-None-Match: *. That's why these go wrong. How two fix the bugs: - There are two alternatives: fix only for mod_dav (it is very important) or fix in general (would be nice). Fix for mod_dav only: There are two patches (as far as I can see): http://issues.apache.org/bugzilla/attachment.cgi?id=20552 (from me) and http://mail-archives.apache.org/mod_mbox/httpd-dev/200710.mbox/[EMAIL PROTECTED] (from Paritosh Shah) These two patches are not competing. They do fundamentaly the same, but the second one (from Paritosh) is the cleaner one. Fix it in general: Even a general solution will still have to fix the bug in mod_dav. There is a patch from Paritosh http://mail-archives.apache.org/mod_mbox/httpd-dev/200710.mbox/raw/[EMAIL PROTECTED]/3 To fix the problem with ap_meets_conditions in general, a change in its interface is necessary, to provide ap_meets_conditions with information about the existence of the file. There has been some discussion about how to do this interface change. In my opinion, the best solution is suggested by Paritosh in http://mail-archives.apache.org/mod_mbox/httpd-dev/200711.mbox/[EMAIL PROTECTED] The changes of the code in ap_meets_conditions(2?) should be exactly the ones in http://mail-archives.apache.org/mod_mbox/httpd-dev/200710.mbox/raw/[EMAIL PROTECTED]/2 But editorial changes are necessary, depending on how the interface will be changed exactly. As I understand, Paritosh would be willing, to provide a complete working patch for the general solution. But I also understand, that Tim Olsen would not be fond of wasting time on creating fine patches, that will be ignored anyway. My Proposal: Use the mod_dav-only patch as an intermediate solution, because it is urgent. This solution will not touch anything but mod_dav and can be removed without side effects as soon as a general solution is available. Take the time to consider how to change the interface of ap_meets_conditions (there might be more issues related to this) and include a clean general solution in 2.2.8. Competing Patches - The only competing patch I know of is http://issues.apache.org/bugzilla/attachment.cgi?id=21295 It just does not work, because it ignores half of the bugs and relies on assumptions that are most probably wrong. Werner
Re: time for 1.3.40 and 2.2.7 ?
Here's what I'd like to propose: o) We do another triple release: 1.3.40, 2.0.62 and 2.2.7 o) I tag and roll all 3 this Saturday (Dec 29th) o) We anticipate releasing/announcing all on Jan 2, 2008 It would be a great New Year's gift to the community :)
Re: time for 1.3.40 and 2.2.7 ?
Hi Jim, Here's what I'd like to propose: o) We do another triple release: 1.3.40, 2.0.62 and 2.2.7 o) I tag and roll all 3 this Saturday (Dec 29th) o) We anticipate releasing/announcing all on Jan 2, 2008 It would be a great New Year's gift to the community :) great! Hehe, new update work for the admins!! would you agree that I commit this type correction to mod_ssl 2.0.x? votes from Bill and me, and one missing http://people.apache.org/~fuankg/diffs/ssl_scache_shmht.c.diff --- ssl_scache_shmht.c.orig Wed Jul 12 09:40:56 2006 +++ ssl_scache_shmht.c Sun Nov 25 17:32:58 2007 @@ -198,7 +198,7 @@ SSLModConfigRec *mc = myModConfig(s); void *vp; SSL_SESSION *sess = NULL; -UCHAR *ucpData; +MODSSL_D2I_SSL_SESSION_CONST UCHAR *ucpData; int nData; time_t expiry; time_t now; @@ -223,7 +223,7 @@ return NULL; } memcpy(expiry, vp, sizeof(time_t)); -memcpy(ucpData, (char *)vp+sizeof(time_t), nData); +memcpy((void *)ucpData, (char *)vp+sizeof(time_t), nData); ssl_mutex_off(s); /* make sure the stuff is still not expired */ thanks, Guenter.
Re: time for 1.3.40 and 2.2.7 ?
On 12/27/2007 06:39 PM, Guenter Knauf wrote: Hi Jim, Here's what I'd like to propose: o) We do another triple release: 1.3.40, 2.0.62 and 2.2.7 o) I tag and roll all 3 this Saturday (Dec 29th) o) We anticipate releasing/announcing all on Jan 2, 2008 It would be a great New Year's gift to the community :) great! Hehe, new update work for the admins!! would you agree that I commit this type correction to mod_ssl 2.0.x? votes from Bill and me, and one missing Hm. I see no backport proposal for this in the STATUS file for 2.0.x. For formal reasons please add one. I would be +1 as well. Regards Rüdiger
Re: time for 1.3.40 and 2.2.7 ?
On 12/27/2007 03:45 PM, Jim Jagielski wrote: Here's what I'd like to propose: o) We do another triple release: 1.3.40, 2.0.62 and 2.2.7 o) I tag and roll all 3 this Saturday (Dec 29th) o) We anticipate releasing/announcing all on Jan 2, 2008 It would be a great New Year's gift to the community :) +1 from me. But there is still a show stopper in the 2.0.x STATUS file that misses one vote. Regards Rüdiger
Re: time for 1.3.40 and 2.2.7 ?
On 12/27/2007 11:01 PM, William A. Rowe, Jr. wrote: Guenter Knauf wrote: Hi Ruediger, Hm. I see no backport proposal for this in the STATUS file for 2.0.x. For formal reasons please add one. I would be +1 as well. sorry, but unfortunately that's not possible since 2.2.x and later do not have this file any longer - so there's no real backport proposal possible therefore I dont know how I should express the proposal ...? There's really no difference between STATUS, and on list discussion. The advantage to STATUS is reminding people to review over the long haul, the advantage to the list is collecting a quick three votes (when folks are paying attention). The advantage of the STATUS file is that all voting is in one place and it would be IMHO easier to follow voting decisions later on via the svn hiistory. But yes, you are correct. Formally adding to the STATUS file is not required and getting three +1's on the list is the same (I forgot about this). As we have now three +1's (Guenther, you and me) we should not waste further time with formal discussions (which I started :-)). So Guenther please go ahead with committing to the 2.0.x branch. Regards Rüdiger
Re: time for 1.3.40 and 2.2.7 ?
Guenter Knauf wrote: Hi Ruediger, Hm. I see no backport proposal for this in the STATUS file for 2.0.x. For formal reasons please add one. I would be +1 as well. sorry, but unfortunately that's not possible since 2.2.x and later do not have this file any longer - so there's no real backport proposal possible therefore I dont know how I should express the proposal ...? There's really no difference between STATUS, and on list discussion. The advantage to STATUS is reminding people to review over the long haul, the advantage to the list is collecting a quick three votes (when folks are paying attention). I disagree with Ruediger that any extra STATUS step is really needed.
Re: time for 1.3.40 and 2.2.7 ?
On 12/27/2007 10:45 PM, Guenter Knauf wrote: Hi Ruediger, Hm. I see no backport proposal for this in the STATUS file for 2.0.x. For formal reasons please add one. I would be +1 as well. sorry, but unfortunately that's not possible since 2.2.x and later do not have this file any longer - so there's no real backport proposal possible therefore I dont know how I should express the proposal ...? You can just write that in the trunk part of your proposal: Trunk version of patch: File no longer present on trunk Regards Rüdiger
Re: time for 1.3.40 and 2.2.7 ?
Hi Ruediger, Hm. I see no backport proposal for this in the STATUS file for 2.0.x. For formal reasons please add one. I would be +1 as well. sorry, but unfortunately that's not possible since 2.2.x and later do not have this file any longer - so there's no real backport proposal possible therefore I dont know how I should express the proposal ...? Guenter.
Re: time for 1.3.40 and 2.2.7 ?
Hi, As we have now three +1's (Guenther, you and me) we should not waste further time with formal discussions (which I started :-)). So Guenther please go ahead with committing to the 2.0.x branch. thanks; done: http://svn.apache.org/viewvc?rev=607132view=rev Guen.
Re: time for 1.3.40 and 2.2.7 ?
Hi, any chance we can get this simple patch in to correct a type mismatch which bothers me all the time when compiling with OpenSSL 0.9.8 on NetWare? http://people.apache.org/~fuankg/diffs/ssl_scache_shmht.c.diff --- ssl_scache_shmht.c.orig Wed Jul 12 09:40:56 2006 +++ ssl_scache_shmht.c Sun Nov 25 17:32:58 2007 @@ -198,7 +198,7 @@ SSLModConfigRec *mc = myModConfig(s); void *vp; SSL_SESSION *sess = NULL; -UCHAR *ucpData; +MODSSL_D2I_SSL_SESSION_CONST UCHAR *ucpData; int nData; time_t expiry; time_t now; @@ -223,7 +223,7 @@ return NULL; } memcpy(expiry, vp, sizeof(time_t)); -memcpy(ucpData, (char *)vp+sizeof(time_t), nData); +memcpy((void *)ucpData, (char *)vp+sizeof(time_t), nData); ssl_mutex_off(s); /* make sure the stuff is still not expired */ Are you certain (void *)ucpData cast is actually useful? I was pretty certain memcpy is more tolerant than that. unfortunately not - our NetWare compiler breaks without. The only alternative patch would be: --- ssl_scache_shmht.c.orig Wed Jul 12 09:40:56 2006 +++ ssl_scache_shmht.c Sun Nov 25 17:01:26 2007 @@ -234,7 +234,8 @@ } /* unstreamed SSL_SESSION */ -sess = d2i_SSL_SESSION(NULL, ucpData, nData); +sess = d2i_SSL_SESSION(NULL, +(MODSSL_D2I_SSL_SESSION_CONST UCHAR **)ucpData, nData); return sess; } About the rest of it, +1 thanks. Guenter.
Re: time for 1.3.40 and 2.2.7 ?
Hi, On Dec 14, 2007, at 12:52 PM, William A. Rowe, Jr. wrote: Jim Jagielski wrote: Anyone opposed to us shooting for a TR early next week? If we can get a couple of security-related-but-not-really patches committed to 2.0 I'd like to see that as well. I'm offering, Sure... that would be great. Another three-for-all :) From what I can see, both 1.3 and 2.2 are backport free, so it's just 2.0 right now. any chance we can get this simple patch in to correct a type mismatch which bothers me all the time when compiling with OpenSSL 0.9.8 on NetWare? http://people.apache.org/~fuankg/diffs/ssl_scache_shmht.c.diff --- ssl_scache_shmht.c.orig Wed Jul 12 09:40:56 2006 +++ ssl_scache_shmht.c Sun Nov 25 17:32:58 2007 @@ -198,7 +198,7 @@ SSLModConfigRec *mc = myModConfig(s); void *vp; SSL_SESSION *sess = NULL; -UCHAR *ucpData; +MODSSL_D2I_SSL_SESSION_CONST UCHAR *ucpData; int nData; time_t expiry; time_t now; @@ -223,7 +223,7 @@ return NULL; } memcpy(expiry, vp, sizeof(time_t)); -memcpy(ucpData, (char *)vp+sizeof(time_t), nData); +memcpy((void *)ucpData, (char *)vp+sizeof(time_t), nData); ssl_mutex_off(s); /* make sure the stuff is still not expired */ Guenter.
Re: time for 1.3.40 and 2.2.7 ?
Guenter Knauf wrote: Hi, On Dec 14, 2007, at 12:52 PM, William A. Rowe, Jr. wrote: Jim Jagielski wrote: Anyone opposed to us shooting for a TR early next week? If we can get a couple of security-related-but-not-really patches committed to 2.0 I'd like to see that as well. I'm offering, Sure... that would be great. Another three-for-all :) From what I can see, both 1.3 and 2.2 are backport free, so it's just 2.0 right now. any chance we can get this simple patch in to correct a type mismatch which bothers me all the time when compiling with OpenSSL 0.9.8 on NetWare? http://people.apache.org/~fuankg/diffs/ssl_scache_shmht.c.diff --- ssl_scache_shmht.c.orig Wed Jul 12 09:40:56 2006 +++ ssl_scache_shmht.c Sun Nov 25 17:32:58 2007 @@ -198,7 +198,7 @@ SSLModConfigRec *mc = myModConfig(s); void *vp; SSL_SESSION *sess = NULL; -UCHAR *ucpData; +MODSSL_D2I_SSL_SESSION_CONST UCHAR *ucpData; int nData; time_t expiry; time_t now; @@ -223,7 +223,7 @@ return NULL; } memcpy(expiry, vp, sizeof(time_t)); -memcpy(ucpData, (char *)vp+sizeof(time_t), nData); +memcpy((void *)ucpData, (char *)vp+sizeof(time_t), nData); ssl_mutex_off(s); /* make sure the stuff is still not expired */ Are you certain (void *)ucpData cast is actually useful? I was pretty certain memcpy is more tolerant than that. About the rest of it, +1 Bill
Re: time for 1.3.40 and 2.2.7 ?
Den Friday 14 December 2007 22.09.00 skrev William A. Rowe, Jr.: William A. Rowe, Jr. wrote: There's a simple way of not-so-rudely saying ... Sorry if this came across harshly Odin, I watch those dialogs daily on php-dev, I'd hate to see httpd-dev polluted with the same volume of self interest and vitriol. Let me make sure I answered what you might have been asking... I was just curious about this. I didn't know the release procedure was such a pain. You explained it well in your previous mail, thanks. I know about the peanut gallery, I don't want to go there :-). As you may know I maintain apache and loads of third party apache modules in Mandriva Linux. I'm not authorized to vote here, for that I need to reincarnate myself as an ASF developer I guess. Keep up the good work. -- Regards // Oden Eriksson
Re: time for 1.3.40 and 2.2.7 ?
On Dec 17, 2007, at 1:48 AM, Oden Eriksson wrote: apache and loads of third party apache modules in Mandriva Linux. I'm not authorized to vote here, for that I need to reincarnate myself as an ASF developer I guess. As far as I see it, *any* feedback from *anyone* on a release candidate is highly appreciated, regardless of whether that person's vote is binding. For instance, I don't know if anyone on the PMC is running Mandriva on a regular basis. Your scrutiny and response to a release candidate in the form of a +1 or -1 (and here's why) vote would carry great weight, even if it wouldn't directly count towards the release votes cast by the PMC members. S. -- Sander Temme [EMAIL PROTECTED] PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: time for 1.3.40 and 2.2.7 ?
-Ursprüngliche Nachricht- Von: Jim Jagielski Gesendet: Freitag, 14. Dezember 2007 14:49 An: dev@httpd.apache.org Betreff: Re: time for 1.3.40 and 2.2.7 ? Anyone opposed to us shooting for a TR early next week? No. Let's rock. I offer to RM Thanks for doing so. Regards Rüdiger
Re: time for 1.3.40 and 2.2.7 ?
Anyone opposed to us shooting for a TR early next week? I offer to RM
Re: time for 1.3.40 and 2.2.7 ?
Jim Jagielski wrote: Anyone opposed to us shooting for a TR early next week? If we can get a couple of security-related-but-not-really patches committed to 2.0 I'd like to see that as well. I'm offering, but if you would enjoy it, I'll just focus on win32 src/binary packages all around. Bill
Re: time for 1.3.40 and 2.2.7 ?
On Dec 14, 2007, at 12:52 PM, William A. Rowe, Jr. wrote: Jim Jagielski wrote: Anyone opposed to us shooting for a TR early next week? If we can get a couple of security-related-but-not-really patches committed to 2.0 I'd like to see that as well. I'm offering, Sure... that would be great. Another three-for-all :) From what I can see, both 1.3 and 2.2 are backport free, so it's just 2.0 right now.
Re: time for 1.3.40 and 2.2.7 ?
Den Friday 14 December 2007 20.24.35 skrev Jim Jagielski: On Dec 14, 2007, at 12:52 PM, William A. Rowe, Jr. wrote: Jim Jagielski wrote: Anyone opposed to us shooting for a TR early next week? If we can get a couple of security-related-but-not-really patches committed to 2.0 I'd like to see that as well. I'm offering, Sure... that would be great. Another three-for-all :) From what I can see, both 1.3 and 2.2 are backport free, so it's just 2.0 right now. It's some obsession to release more than just one? I would rather see 2.2.7 released now. I don't care at all about 1.3.x or 2.0.x. -- Regards // Oden Eriksson
Re: time for 1.3.40 and 2.2.7 ?
Oden Eriksson wrote: Den Friday 14 December 2007 20.24.35 skrev Jim Jagielski: From what I can see, both 1.3 and 2.2 are backport free, so it's just 2.0 right now. Yup - and the review of significant 2.0 patches would only take an hour or two, it's not that complex - things that were already accepted and happily adopted for 2.2. It's some obsession to release more than just one? I would rather see 2.2.7 released now. I don't care at all about 1.3.x or 2.0.x. It's simply time consuming for the RM to package /anything/. Nevermind put it up for a vote, update the websites, send out the announcements and so forth. So it's really an RM's call what they want to proceed with, we all appreciate that. There are economies of scale; once you have to dig into 10 different places to update it all, changing 3 instead of just 1 is pretty trivial. Changing it all one at a time for one release over and over again is a PITA. I've RM'ed my share of httpd releases, and know this from experience. However, if just one of those three falls over, and can't be released, that should not stop any other good candidates from becoming released promptly, so RM'ing two extra tarballs really doesn't add as much work as you might expect. So I offered to package 2.0, because I don't want to force it on anyone else who doesn't care. I was guessing Jim might want to RM all three, but that's his call, I'm happy either way. Either Jim, or I, or any other RM who goes to the effort deserves our appreciation. There's a simple way of not-so-rudely saying what you just said above. Just don't test the package you don't care about, don't put in a vote either way, and certainly don't play peanut gallery if you have nothing productive to add. Bill
Re: time for 1.3.40 and 2.2.7 ?
William A. Rowe, Jr. wrote: There's a simple way of not-so-rudely saying ... Sorry if this came across harshly Odin, I watch those dialogs daily on php-dev, I'd hate to see httpd-dev polluted with the same volume of self interest and vitriol. Let me make sure I answered what you might have been asking... One thing I *wasn't* suggesting was to hold off 2.2 for some magical activity on 2.0; the security fix is already in, the sort-of-security-related fixes to methods are ready to commit, missing one last +1. There are a few others, but if people can't review them this weekend, I agree Jim shouldn't be pushed to change his game plan at all. Early next week really sounds great to me. Bill
Re: time for 1.3.40 and 2.2.7 ?
On 12/14/2007 08:24 PM, Jim Jagielski wrote: On Dec 14, 2007, at 12:52 PM, William A. Rowe, Jr. wrote: Jim Jagielski wrote: Anyone opposed to us shooting for a TR early next week? If we can get a couple of security-related-but-not-really patches committed to 2.0 I'd like to see that as well. I'm offering, Sure... that would be great. Another three-for-all :) From what I can see, both 1.3 and 2.2 are backport There is one open for 2.2.x which seems to be a low hanging fruit and only missing one vote regarding mod_ssl. Would be nice to have this one in. Regards Rüdiger
Re: time for 1.3.40 and 2.2.7 ?
Hi, Jim Jagielski schrieb: From what I can see, both 1.3 and 2.2 are backport free, so it's just 2.0 right now. maybe a good candidate for inclusion in 2.0 would be http://issues.apache.org/bugzilla/show_bug.cgi?id=43943 shmcb crash on Sparc when compiled with gcc 4. It has been fixed with a noinline compiler attribute for 2.2.x in 2006 and the same fix applies and works for 2.0.x to: http://svn.apache.org/viewvc?view=revrevision=382799 Regards, Rainer
Re: time for 1.3.40 and 2.2.7 ?
On 12/10/2007 08:31 AM, Mladen Turk wrote: Ruediger Pluem wrote: Are you talking about #define AJP_MAX_BUFFER_SZ 16384 in ajp.h? If yes, it was you in r467257 :-). ROTFL :-) I'm definitely getting older. Anyhow the max is 64K, so it should be updated accordingly to mod_jk and what Tomcat accepts. Just curious, where can this be found in mod_jk? A quick check neither revealed this in the source of 1.2.25 nor in the docs. Maybe I just missed it. Regards Rüdiger
Re: time for 1.3.40 and 2.2.7 ?
Ruediger Pluem wrote: On 12/10/2007 08:31 AM, Mladen Turk wrote: Ruediger Pluem wrote: Are you talking about #define AJP_MAX_BUFFER_SZ 16384 in ajp.h? If yes, it was you in r467257 :-). ROTFL :-) I'm definitely getting older. Anyhow the max is 64K, so it should be updated accordingly to mod_jk and what Tomcat accepts. Just curious, where can this be found in mod_jk? A quick check neither revealed this in the source of 1.2.25 nor in the docs. Maybe I just missed it. It is since 1.2.19, check for max_packet_size. http://tomcat.apache.org/connectors-doc/reference/workers.html Regards, Mladen
Re: time for 1.3.40 and 2.2.7 ?
On 12/10/2007 10:26 AM, Mladen Turk wrote: It is since 1.2.19, check for max_packet_size. http://tomcat.apache.org/connectors-doc/reference/workers.html Thanks for the pointer. Regards Rüdiger
Re: time for 1.3.40 and 2.2.7 ?
On Dec 9, 2007, at 10:30 AM, Ruediger Pluem wrote: On 12/08/2007 04:04 PM, Ruediger Pluem wrote: On 11/27/2007 07:26 PM, Jim Jagielski wrote: With APR now out, I think we're close to releasing 1.3.40 and 2.2.7... Anyone opposed with that gameplan? There are 9 backport proposals currently in the STATUS file and 7 of them only miss one vote. The two remaining ones only require some more or less large adjustments to the proposal and should miss only one vote after that. So come on folks take some time and do some reviews please. Jim and I have only one vote :-). It would be really cool to get them in 2.2.7. Sorry for being so impatient :-). Thanks folks for all the reviewing work done. From my perspective there is now nothing left between us and 2.2.7. Jim do you still volunteer to RM? Yep, but there are, iirc, one or 2 other issues that need to be addressed before we're ready for 2.2.7... I'm guessing early next week is a good time to shoot for.
Re: time for 1.3.40 and 2.2.7 ?
On 12/08/2007 04:04 PM, Ruediger Pluem wrote: On 11/27/2007 07:26 PM, Jim Jagielski wrote: With APR now out, I think we're close to releasing 1.3.40 and 2.2.7... Anyone opposed with that gameplan? There are 9 backport proposals currently in the STATUS file and 7 of them only miss one vote. The two remaining ones only require some more or less large adjustments to the proposal and should miss only one vote after that. So come on folks take some time and do some reviews please. Jim and I have only one vote :-). It would be really cool to get them in 2.2.7. Sorry for being so impatient :-). Thanks folks for all the reviewing work done. From my perspective there is now nothing left between us and 2.2.7. Jim do you still volunteer to RM? Regards Rüdiger
Re: time for 1.3.40 and 2.2.7 ?
Hi, On 12/08/2007 04:04 PM, Ruediger Pluem wrote: Thanks folks for all the reviewing work done. From my perspective there is now nothing left between us and 2.2.7. Jim do you still volunteer to RM? I see a new small issue with mod_proxy_ajp which I've not yet tracked down; maybe my config is wrong, but now with recent code I see warnings when I start Apache which I didnt see with 2.2.6 with same config; I will try to track down this... Guenter.
Re: time for 1.3.40 and 2.2.7 ?
On 12/09/2007 04:47 PM, Guenter Knauf wrote: Hi, On 12/08/2007 04:04 PM, Ruediger Pluem wrote: Thanks folks for all the reviewing work done. From my perspective there is now nothing left between us and 2.2.7. Jim do you still volunteer to RM? I see a new small issue with mod_proxy_ajp which I've not yet tracked down; maybe my config is wrong, but now with recent code I see warnings when I start Apache which I didnt see with 2.2.6 with same config; I will try to track down this... Could you please post these warning messages and your config, such that others can have a view in parallel? Regards Rüdiger
Re: time for 1.3.40 and 2.2.7 ?
Hi Ruediger, On 12/09/2007 04:47 PM, Guenter Knauf wrote: Could you please post these warning messages and your config, such that others can have a view in parallel? sure; warnings: [Sat Dec 08 22:07:12 2007] [warn] worker ajp://localhost:9009 already used by another worker [Sat Dec 08 22:07:12 2007] [warn] worker ajp://localhost:9009 already used by another worker my cofig which previous seemed to work with 2.2.6: # # Configuration for mod_proxy_ajp # IfModule !proxy_module LoadModule proxy_module modules/proxy.nlm /IfModule IfModule !proxy_ajp_module LoadModule proxy_ajp_module modules/proxyajp.nlm /IfModule IfModule proxy_ajp_module # ProxyRequests Off # AJP13 Single Proxy ProxyPass /tc-s ajp://localhost:58009 # Locations to some Java Apps Location /servlet-examples/ ProxyPass ajp://localhost:9009 /Location Location /jsp-examples/ ProxyPass ajp://localhost:9009 /Location Location /tomcat-docs/ ProxyPass ajp://localhost:9009 /Location /IfModule # End of mod_proxy_ajp. Guenter.
Re: time for 1.3.40 and 2.2.7 ?
Guenter Knauf wrote: On 12/08/2007 04:04 PM, Ruediger Pluem wrote: Thanks folks for all the reviewing work done. From my perspective there is now nothing left between us and 2.2.7. Jim do you still volunteer to RM? I see a new small issue with mod_proxy_ajp which I've not yet tracked down; maybe my config is wrong, but now with recent code I see warnings when I start Apache which I didnt see with 2.2.6 with same config; I will try to track down this... Now that you bring up mod_proxy_ajp... Has the flexible packet size stuff been backported to 2.2.x yet? This stuff is important for some cases. mod_jk has it and I believe trunk does as well. -- Jess Holle
Re: time for 1.3.40 and 2.2.7 ?
Ruediger Pluem wrote: Thanks folks for all the reviewing work done. From my perspective there is now nothing left between us and 2.2.7. FYI you failed to backport the win32 build file to mod_substitute, so I'll go ahead and do that along with review the entire package today so it's ready as a stable release. News later today.
Re: time for 1.3.40 and 2.2.7 ?
On Sun, 09 Dec 2007 16:30:05 +0100 Ruediger Pluem [EMAIL PROTECTED] wrote: Thanks folks for all the reviewing work done. From my perspective there is now nothing left between us and 2.2.7. Oops, there's an unexpected proxy compliance violation (fails to subtract Max-Forwards of 1 in Trace and Options requests). Report: http://people.apache.org/~niq/coadvisor/2.2-dec9.html#violation Investigating now. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: time for 1.3.40 and 2.2.7 ?
On Sun, 9 Dec 2007 18:09:41 + Nick Kew [EMAIL PROTECTED] wrote: Oops, there's an unexpected proxy compliance violation (fails to subtract Max-Forwards of 1 in Trace and Options requests). Report: http://people.apache.org/~niq/coadvisor/2.2-dec9.html#violation Investigating now. The fault was in r582635, which included an incorrect backport of r581117! Just fixed in r602715. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: time for 1.3.40 and 2.2.7 ?
Jess Holle wrote: Now that you bring up mod_proxy_ajp... Has the flexible packet size stuff been backported to 2.2.x yet? This stuff is important for some cases. mod_jk has it and I believe trunk does as well. It does, but don't know why it was limited to the 16384 bytes, and who committed that, while in mod_jk its 65536 and it works perfectly. I'll propose the backport for sure cause 64K is ajp protocol limit (and Tomcat will accept it) Regards, Mladen
Re: time for 1.3.40 and 2.2.7 ?
Thanks! -- Jess Holle Mladen Turk wrote: Jess Holle wrote: Now that you bring up mod_proxy_ajp... Has the flexible packet size stuff been backported to 2.2.x yet? This stuff is important for some cases. mod_jk has it and I believe trunk does as well. It does, but don't know why it was limited to the 16384 bytes, and who committed that, while in mod_jk its 65536 and it works perfectly. I'll propose the backport for sure cause 64K is ajp protocol limit (and Tomcat will accept it) Regards, Mladen
Re: time for 1.3.40 and 2.2.7 ?
Hi, question regarding mod_substitute docu: This is an experimental module and should be used with care. should this warning remain now that its moved out of experimental? Guenter.
Re: time for 1.3.40 and 2.2.7 ?
On 12/09/2007 10:02 PM, Guenter Knauf wrote: Hi, question regarding mod_substitute docu: This is an experimental module and should be used with care. should this warning remain now that its moved out of experimental? +1 to remove experimental from the docs. Regards Rüdiger
Re: time for 1.3.40 and 2.2.7 ?
On 12/09/2007 08:30 PM, Mladen Turk wrote: Jess Holle wrote: Now that you bring up mod_proxy_ajp... Has the flexible packet size stuff been backported to 2.2.x yet? This stuff is important for some cases. mod_jk has it and I believe trunk does as well. It does, but don't know why it was limited to the 16384 bytes, and who committed that, while in mod_jk its 65536 and it works perfectly. Are you talking about #define AJP_MAX_BUFFER_SZ 16384 in ajp.h? If yes, it was you in r467257 :-). Regards Rüdiger
Re: time for 1.3.40 and 2.2.7 ?
Ruediger Pluem wrote: On 12/09/2007 10:02 PM, Guenter Knauf wrote: Hi, question regarding mod_substitute docu: This is an experimental module and should be used with care. should this warning remain now that its moved out of experimental? +1 to remove experimental from the docs. +1 from me too.
Re: time for 1.3.40 and 2.2.7 ?
Ruediger Pluem wrote: Are you talking about #define AJP_MAX_BUFFER_SZ 16384 in ajp.h? If yes, it was you in r467257 :-). ROTFL :-) I'm definitely getting older. Anyhow the max is 64K, so it should be updated accordingly to mod_jk and what Tomcat accepts. Cheers, Mladen
Re: time for 1.3.40 and 2.2.7 ?
On 12/09/2007 08:04 PM, Guenter Knauf wrote: however this works not - does the $1 only work for AliasMatch and not with LocationMatch? LocationMatch /examples/(jsp|servlet|servlets) ProxyPass ajp://localhost:58009/examples/$1 /LocationMatch Have you tried to use ProxyPassMatch instead of ProxyPass? Regards Rüdiger
Re: time for 1.3.40 and 2.2.7 ?
On 11/27/2007 07:26 PM, Jim Jagielski wrote: With APR now out, I think we're close to releasing 1.3.40 and 2.2.7... Anyone opposed with that gameplan? There are 9 backport proposals currently in the STATUS file and 7 of them only miss one vote. The two remaining ones only require some more or less large adjustments to the proposal and should miss only one vote after that. So come on folks take some time and do some reviews please. Jim and I have only one vote :-). It would be really cool to get them in 2.2.7. Sorry for being so impatient :-). Regards Rüdiger
Re: time for 1.3.40 and 2.2.7 ?
On Sat, 08 Dec 2007 16:04:21 +0100 Ruediger Pluem [EMAIL PROTECTED] wrote: There are 9 backport proposals currently in the STATUS file and 7 of them only miss one vote. The two remaining ones only require some more or less large adjustments to the proposal and should miss only one vote after that. Just made a small update. More to come, time permitting. At this stage, we might want to make a distinction between must have and can wait in backport proposals. So a fix for a serious bug gets priority attention over a new feature, and a simple proposal can be promoted over one that's time-consuming to review. Just a thought. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: time for 1.3.40 and 2.2.7 ?
-Ursprüngliche Nachricht- Von: Ruediger Pluem Gesendet: Dienstag, 27. November 2007 21:26 An: dev@httpd.apache.org Betreff: Re: time for 1.3.40 and 2.2.7 ? On 11/27/2007 07:26 PM, Jim Jagielski wrote: With APR now out, I think we're close to releasing 1.3.40 and 2.2.7... Anyone opposed with that gameplan? Sounds very good for me. I think there is only one issue left that needs fixing: The fd leaking on Windows for which Bill proposed a backport and I added a comment. Meanwhile I withdrew my comment / objection as I could not follow my own arguments during a second review. I guess I missed one dup2 call on the way what lead to my initial comment. So I am now +1 on the proposal. So from my point of view only the review of the low hanging fruits in the STATUS file is between us and 2.2.7. Regards Rüdiger
Re: time for 1.3.40 and 2.2.7 ?
On 11/27/2007 07:26 PM, Jim Jagielski wrote: With APR now out, I think we're close to releasing 1.3.40 and 2.2.7... Anyone opposed with that gameplan? Sounds very good for me. I think there is only one issue left that needs fixing: The fd leaking on Windows for which Bill proposed a backport and I added a comment. Other than that I guess we should only finish the low hanging fruits from the STATUS file and get most of 'the missing one vote' proposals into the release. But this should not hold us back longer from a release as the fd leaking problem does. Regards Rüdiger
