Re: Custom Listen statement in perl-framework (Was: Re: [VOTE] 2.2.2 Candidate)
resending to all the interested lists... Sander Temme wrote: > > On Apr 23, 2006, at 9:37 AM, Paul Querna wrote: > >> Sander Temme wrote: >> >>> FreeBSD bagheera.sandla.org. 6.1-RC FreeBSD 6.1-RC #3: Fri Apr 21 >>> 08:35:33 PDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/ >>> src/sys/GENERIC i386 >>> Testsuite currently unusable, hangs on: >>> t/protocol/nntp-likeok 1/10 >>> This seems to be a local issue. Anyone else seeing this happen on >>> FreeBSD? No crashes on minotaur which is also FreeBSD. I will advise >>> when the 72 hour window is up. >> >> >> AFAIK, This test fails on all FreeBSD machines. >> >> Adding the following to the config file for this test should fix it: >> AcceptFilter nntp none >> Listen 119 nntp >> (Or whatever port it is running on) > > > Actually, the port is determined on the fly by the testsuite, all the > configuration language available in the mod_nntp_like.c file is the > following: > > #if CONFIG_FOR_HTTPD_TEST > > > NNTPLike On > > > > > NNTPLike On > SSLEngine On > > > > #endif > > The slightly perverted VirtualHost statement seems to be converted by > the testsuite into a combination of: > > Listen 0.0.0.0:8530 > > ServerName localhost.localdomain:8530 > NNTPLike On > that's all accurate. > > So my question, especially to the perl-framework gurus, is how do I add > a custom configuration option to that Listen statement? so, you want something like this eventually Listen 0.0.0.0:8530 nntp AcceptFilter nntp none ... ? I don't think you can currently do that with the framework. I might be able to work up something like Listen mod_nntp_like nntp so that the "mod_nntp_like" would expand out to match the way we do the vhost sections (though it's adding yet more black magic). it might take me a while to get around to it, but I could probably work on it "soonish" is there no other way to handle this config wise? --Geoff
Re: Custom Listen statement in perl-framework (Was: Re: [VOTE] 2.2.2 Candidate)
Sander Temme wrote: > > On Apr 23, 2006, at 9:37 AM, Paul Querna wrote: > >> Sander Temme wrote: >> >>> FreeBSD bagheera.sandla.org. 6.1-RC FreeBSD 6.1-RC #3: Fri Apr 21 >>> 08:35:33 PDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/ >>> src/sys/GENERIC i386 >>> Testsuite currently unusable, hangs on: >>> t/protocol/nntp-likeok 1/10 >>> This seems to be a local issue. Anyone else seeing this happen on >>> FreeBSD? No crashes on minotaur which is also FreeBSD. I will advise >>> when the 72 hour window is up. >> >> >> AFAIK, This test fails on all FreeBSD machines. >> >> Adding the following to the config file for this test should fix it: >> AcceptFilter nntp none >> Listen 119 nntp >> (Or whatever port it is running on) > > > Actually, the port is determined on the fly by the testsuite, all the > configuration language available in the mod_nntp_like.c file is the > following: > > #if CONFIG_FOR_HTTPD_TEST > > > NNTPLike On > > > > > NNTPLike On > SSLEngine On > > > > #endif > > The slightly perverted VirtualHost statement seems to be converted by > the testsuite into a combination of: > > Listen 0.0.0.0:8530 > > ServerName localhost.localdomain:8530 > NNTPLike On > that's all accurate. > > So my question, especially to the perl-framework gurus, is how do I add > a custom configuration option to that Listen statement? so, you want something like this eventually Listen 0.0.0.0:8530 nntp AcceptFilter nntp none ... ? I don't think you can currently do that with the framework. I might be able to work up something like Listen mod_nntp_like nntp so that the "mod_nntp_like" would expand out to match the way we do the vhost sections (though it's adding yet more black magic). it might take me a while to get around to it, but I could probably work on it "soonish" is there no other way to handle this config wise? --Geoff
Custom Listen statement in perl-framework (Was: Re: [VOTE] 2.2.2 Candidate)
On Apr 23, 2006, at 9:37 AM, Paul Querna wrote: Sander Temme wrote: FreeBSD bagheera.sandla.org. 6.1-RC FreeBSD 6.1-RC #3: Fri Apr 21 08:35:33 PDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/ src/sys/GENERIC i386 Testsuite currently unusable, hangs on: t/protocol/nntp-likeok 1/10 This seems to be a local issue. Anyone else seeing this happen on FreeBSD? No crashes on minotaur which is also FreeBSD. I will advise when the 72 hour window is up. AFAIK, This test fails on all FreeBSD machines. Adding the following to the config file for this test should fix it: AcceptFilter nntp none Listen 119 nntp (Or whatever port it is running on) Actually, the port is determined on the fly by the testsuite, all the configuration language available in the mod_nntp_like.c file is the following: #if CONFIG_FOR_HTTPD_TEST NNTPLike On NNTPLike On SSLEngine On #endif The slightly perverted VirtualHost statement seems to be converted by the testsuite into a combination of: Listen 0.0.0.0:8530 ServerName localhost.localdomain:8530 NNTPLike On So my question, especially to the perl-framework gurus, is how do I add a custom configuration option to that Listen statement? Thanks, 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: copyright notices
Roy T. Fielding wrote: Wow, this discussion is getting out of hand. Ack, sorry for my contribution to the noise ratio, and our collective frustration, but it's clear the board's entirely failed the projects in this respect; we have alot of folks rethinking the same problem set, spread across many lists, including semi-open legal-discuss and the closed legal-internal and board lists. Frequently these discussion threads come to very different conclusions, which is why only a formal board statement can satisfy, anymore. The problem is, this thread grew explosive that a few argued the change was outwrite invalid, a few that it was irrelevant. In any case, it's the deck chairs of the titanic we are arguing over, they are going overboard in the very near future... So, why didn't I apply the changes to httpd already? The answer is because I am waiting for a board decision, and because the httpd source contains so much collective work that it is very hard to find a file that cannot be argued as (at least) a joint effort by the ASF. +1 - and it's exactly what I expected. On Apr 21, 2006, at 11:46 AM, William A. Rowe, Jr. wrote: This just isn't making sense as I read the svn tree for jackrabbit however. I'm really completely unclear how this protects the files [...] That is irrelevant. They are protected by copyright law, regardless of the notice or lack thereof. The Berne convention is news to me, last week. One question, even if the US is a signatory, is this... has US copyright law been updated to conform to the Berne treaty? US law binds in all cases of US -> US disputes, and also international disputes falling in US jurisdiction. AIUI these must be codified in the law that applies in the US. Thank you for a detailed examination of how the files, copyright and license quoted on this list apply to Jackrabbit! It was rather meaningless out of context for we, the uninformed. I trusted Jackrabbit was right, but pointers into SVN didn't give me any context of how the package is assembled, and what pieces are expected to be cherry-picked by a developer. Jackrabbit is the test animal (so to speak). Let's give the board time to consider what, if anything, should be done for general policy. Of course! I understood from the get-go that Jackrabbit was partly due to the intersection of Day's contribution to the ASF, two clear parties and very clear providence of the code. I don't expect httpd to easily fall into that exact mold. Personally, I think it is part of the board's job (and the chairs, being their conduit) to take care of this legal mumbo jumbo and thus save the developers from having to worry about it. This would be a wonderful thing, yes. Reinventing the wheel times four dozen times over is a pretty horrid waste of our ASF's diverse talent. Bill
Re: Joint Release of all branches
Colm MacCarthaigh wrote: On Mon, Apr 24, 2006 at 01:49:29PM -0500, William A. Rowe, Jr. wrote: What I'd like to propose is 1) wait for the unified announce on Wed night, 2) cease pushing out any 1.3 or 2.0 specific product announcements. Whatever way we end up cutting this, can we agree to at least let packagers@httpd.apache.org know about the 3 different releases? Either all in one go, or seperately. You are the RM (of one of the above) :) I'm a little frustrated though that it would be necessary to add yet another broadcast channel. It's really up to packagers@ to follow announce@ themselves. AIUI packagers@ was a channel for discussing packaging methods, nothing more. If it's reduplicating the efforts of dev@, testers@ and announce@, it's time to shutter it. Bill
Re: Joint Release of all branches
On Mon, Apr 24, 2006 at 01:49:29PM -0500, William A. Rowe, Jr. wrote: > What I'd like to propose is 1) wait for the unified announce on Wed night, > 2) cease pushing out any 1.3 or 2.0 specific product announcements. Whatever way we end up cutting this, can we agree to at least let packagers@httpd.apache.org know about the 3 different releases? Either all in one go, or seperately. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [VOTE] 2.0.58 Candidate
On 04/24/2006 08:40 PM, Colm MacCarthaigh wrote: > O.k., for the last time, hopefully :) A candidate for 2.0.58 is > available for testing and voting at; Hopefully my last +1 on this :-). Regards Rüdiger
Re: Documentation for PythonOption
Deron Meranda wrote: I think the namespace direction you're taking is great. Just to be clear, the dotted-notation is simply that, a notation. The interface to req.get_options() is not changing is it? You are correct, it's just a notation - req.get_options will not change. I also think that a listing of all the reserved or mod_python options in the docs for PythonOption is a very good idea. And it should definitely be mentioned that the entire mod_python.* names are reserved, Good point. and that applications or frameworks are encouraged to implement their own prefix/namespaces for their own options. And another good point. :) I'll include your suggestions in the docs. Thanks, Jim
Re: Joint Release of all branches
Justin Erenkrantz wrote: On 4/24/06, Colm MacCarthaigh <[EMAIL PROTECTED]> wrote: Tbh, I'm -0.5 on this. It's complex enough as it is trying to get releases out, and 1.3 hasn't even tagged yet. My concern is that issuing three announcements in the span of one week is *very* confusing to our users. Either 2.0 and 1.3 get bundled with the 2.2 announcement, or we shouldn't announce those releases at all. I don't think this is *as confusing* as the week we announce, say, just 2.0. They at least will see them all. Five weeks from now, when only an announce from 2.0 is pushed out, that will be more confusing. What I'd like to propose is 1) wait for the unified announce on Wed night, 2) cease pushing out any 1.3 or 2.0 specific product announcements. Vote and promote a release for 1.3 or 2.0 into dist/httpd and update the 2.2 announce file at that time (without broadcast). When the next mainstream release (hopefully very shortly after) is ready to roll, the user will be notified that updated 1.3 and 2.0 legacy releases are available.
Re: [VOTE] Apache HTTP Server 1.3.35 Candidate
On Mon, Apr 24, 2006 at 01:55:37PM -0400, Jim Jagielski wrote: > Please test and vote on releasing Apache httpd 1.3.35 +1, tested on Solaris Sparc and Ubuntu x64 -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
[VOTE] 2.0.58 Candidate
O.k., for the last time, hopefully :) A candidate for 2.0.58 is available for testing and voting at; http://httpd.apache.org/dev/dist/ The MD5sums are; ac732a8b3ec5760baa582888f5dbad66 httpd-2.0.58.tar.bz2 a03eeefee78c01ec24c8671380763860 httpd-2.0.58.tar.gz The code is identical to the previous 2.0.57 candidate save the ap_release.h version numver change. The only material change is the revert of the copyright years. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Joint Release of all branches
On 4/24/06, Sander Temme <[EMAIL PROTECTED]> wrote: > How about, we lead with 2.2.2, and note in the announcement that 2.0 > and 1.3 releases should be available later this week. This goes out > to the Slashdots etc. of this world. When 2.0 and 1.3 are ready, we > can update the website but not send out a release announcement. +1. -- justin
[VOTE] Apache HTTP Server 1.3.35 Candidate
Please test and vote on releasing Apache httpd 1.3.35 Download from: http://httpd.apache.org/dev/dist/ Changes: http://httpd.apache.org/dev/dist/CHANGES_1.3 MD5s: MD5 (apache_1.3.35.tar.Z) = e05c80bd0bffcf90df6c66db88106274 MD5 (apache_1.3.35.tar.gz) = 31f99663028828a8b56633e255ee634e -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http:// www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball."
Re: Joint Release of all branches
On Mon, Apr 24, 2006 at 05:40:45PM +0100, Colm MacCarthaigh wrote: > If you feel that strongly about it, veto the code change, and I'll tag > and roll 2.0.58. O.k., this is coming anyway :) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Joint Release of all branches
On Mon, Apr 24, 2006 at 09:15:01AM -0700, Justin Erenkrantz wrote: > > -1, there's been enough back and forth on this. The current status is > > that the existing candidate is good for release unless people start > > reverting their +1's, which so far - has not happened. > > As I have stated before, I believe it's completely inappropriate for > us to be releasing files with bogus copyright years. I don't think there's any dispute over that. The question is whether this is important enough to waste another release cycle over. Faced with that, I don't see how a legal nit over the copyright line should cause people to have to go to the trouble of testing yet another candidate tarball. As we saw with APR, there are only so many unreleased candidates a group can take before they just stop bothering to test them. There is a complete lack of direction from ASF board/legal on this btw, despite your assertion. If you feel that strongly about it, veto the code change, and I'll tag and roll 2.0.58. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Reverting my vote [was: Re: [VOTE] 2.0.57 candidate]
On Apr 20, 2006, at 3:34 PM, Sander Temme wrote: +1 for release on Ubuntu/x86, FreeBSD 6-STABLE/x86, Darwin/PPC. Sorry, I think we should re-roll with the reverted copyright statements. Since the code is the same and no one reported any technical problems, the new vote should be pretty swift. -1 for release. 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: Joint Release of all branches
On Apr 24, 2006, at 9:15 AM, Justin Erenkrantz wrote: On 4/24/06, Colm MacCarthaigh <[EMAIL PROTECTED]> wrote: Tbh, I'm -0.5 on this. It's complex enough as it is trying to get releases out, and 1.3 hasn't even tagged yet. My concern is that issuing three announcements in the span of one week is *very* confusing to our users. Either 2.0 and 1.3 get bundled with the 2.2 announcement, or we shouldn't announce those releases at all. How about, we lead with 2.2.2, and note in the announcement that 2.0 and 1.3 releases should be available later this week. This goes out to the Slashdots etc. of this world. When 2.0 and 1.3 are ready, we can update the website but not send out a release announcement. For 2.0, we probably should re-roll 2.0.58 with the copyright statement reversion and take a new vote -1, there's been enough back and forth on this. The current status is that the existing candidate is good for release unless people start reverting their +1's, which so far - has not happened. As I have stated before, I believe it's completely inappropriate for us to be releasing files with bogus copyright years. We have been explicitly informed by ASF officers and counsel that placing incorrect copyright years on files is something that we should not be doing. I really don't know how much clearer this issue can be. -- justin I will revert my vote so we can have a re-roll. Re-rolling today should allow us to release 1.3 and 2.0 concurrently, at least. 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: 304 response handling with Apache 2.0.53
On 4/24/06, Swapan Gupta <[EMAIL PROTECTED]> wrote: > > Hi, > > I am using Apache 2.0.53. I am observing that when a 304 "Not Modified" > response is returned accompanied by the "Location" header, the > "Location" does not reach the user. > > I could see that this header is not mentioned in the RFC for 304 > response. However, IIS does send this header back to the user along with > the 304. > > So, I wanted to check if Apache does some special handling restricting > this Response header to be passed back to the user? > > Is this a problem with Apache 2.0.53? If yes, has it been addressed in > any of the future Apache versions? > > Looking forward to your response. I'm not sure what you are trying to do, but RFC 2616 Section 10.3.5 is pretty clear that only certain headers should be sent in a 304, and Location isn't one of them. Joshua.
Re: Joint Release of all branches
On 4/24/06, Colm MacCarthaigh <[EMAIL PROTECTED]> wrote: > Tbh, I'm -0.5 on this. It's complex enough as it is trying to get > releases out, and 1.3 hasn't even tagged yet. My concern is that issuing three announcements in the span of one week is *very* confusing to our users. Either 2.0 and 1.3 get bundled with the 2.2 announcement, or we shouldn't announce those releases at all. > > For 2.0, we probably should re-roll 2.0.58 with the copyright > > statement reversion and take a new vote > > -1, there's been enough back and forth on this. The current status is > that the existing candidate is good for release unless people start > reverting their +1's, which so far - has not happened. As I have stated before, I believe it's completely inappropriate for us to be releasing files with bogus copyright years. We have been explicitly informed by ASF officers and counsel that placing incorrect copyright years on files is something that we should not be doing. I really don't know how much clearer this issue can be. -- justin
Re: [VOTE] 2.2.2 Candidate
On Fri, Apr 21, 2006 at 09:35:23PM -0700, Paul Querna wrote: > Download from: > http://httpd.apache.org/dev/dist/ +1, and in production on ftp.heanet.ie for a day now with no problems. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [VOTE] 2.2.2 Candidate
>>> On 4/21/2006 at 10:35:23 pm, in message <[EMAIL PROTECTED]>, Paul Querna <[EMAIL PROTECTED]> wrote: > Please test and vote on releasing httpd 2.2.2, bundling APR and APR-Util > 1.2.7. > > Download from: > http://httpd.apache.org/dev/dist/ > > Changes: > http://httpd.apache.org/dev/dist/CHANGES_2.2 > > MD5s: > 9c759a9744436de6a6aa2ddbc49d6e81 httpd-2.2.2.tar.bz2 > a0d9f7f6f70110a5965340eb7f3a3e66 httpd-2.2.2.tar.gz > > Thanks, > > -Paul +1 NetWare Brad
Re: Mod_proxy_http ProxyErrorOverride eating cookies
Nick Kew wrote: > On Monday 24 April 2006 11:24, Bart van der Schans wrote: >> Hi all, >> >> I'm quite new to the list, so I'm just wondering how it works. Jeff >> Tharp and I created a bug report and proposed a patch to fix it: >> >> http://issues.apache.org/bugzilla/show_bug.cgi?id=39245 >> >> To me it's seems to be a quite trivial patch for something that is just >> working incorrectly. It looks like "nothing is happening" :( It neither >> accepted nor denied.. > > To break back-compatibility as suggested there would be wrong. I don't think anything will "break". Mod_proxy_http silently removes some lines from the header. Right now it doesn't work as advertised. > But what you suggest makes sense if we make it a configuration > option, maybe by updating the ProxyErrorOverride directive to > enable options to treat redirects either as errors or non-errors. This sound a little weird to me. ProxyErrorOverride should not override non-errors or it should have a different name like ProxyErrorAndRedirectAndInfoOverride. We could add an option ProxyRedirectOverride. I can't think of a situation where you would want this though.. Bart -- Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / http://www.hippo.nl --
Re: Joint Release of all branches
Sander Temme wrote: > > For 1.3, Jim has stated his intention to T&R last Tuesday in order to > align with the other two releases, but I don't think this has > happened yet. Jim, would you have time to roll tomorrow? Otherwise I > may be able to do it, perhaps with a little help from my friends. > Yes, I intend to T/R today. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball."
Re: Joint Release of all branches
Colm MacCarthaigh wrote: > > On Sun, Apr 23, 2006 at 11:20:59PM -0700, Sander Temme wrote: > > It looks like the 2.2.2 RC is the closest to being ready for release, > > with the 72 hour window on www.a.o running out Monday night Pacific. > > However, I would like to urge holding back the release until the > > branches can catch up. > > Tbh, I'm -0.5 on this. It's complex enough as it is trying to get > releases out, and 1.3 hasn't even tagged yet. > I don't think 2.0. and/or 2.2 should wait for 1.3. I can tag 1.3.35 today, but would not be able to release until late Wed or Friday, being offline Tues and Thurs. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball."
Re: Mod_proxy_http ProxyErrorOverride eating cookies
On Monday 24 April 2006 11:24, Bart van der Schans wrote: > Hi all, > > I'm quite new to the list, so I'm just wondering how it works. Jeff > Tharp and I created a bug report and proposed a patch to fix it: > > http://issues.apache.org/bugzilla/show_bug.cgi?id=39245 > > To me it's seems to be a quite trivial patch for something that is just > working incorrectly. It looks like "nothing is happening" :( It neither > accepted nor denied.. To break back-compatibility as suggested there would be wrong. But what you suggest makes sense if we make it a configuration option, maybe by updating the ProxyErrorOverride directive to enable options to treat redirects either as errors or non-errors. -- Nick Kew
Re: Mod_proxy_http ProxyErrorOverride eating cookies
Hi all, I'm quite new to the list, so I'm just wondering how it works. Jeff Tharp and I created a bug report and proposed a patch to fix it: http://issues.apache.org/bugzilla/show_bug.cgi?id=39245 To me it's seems to be a quite trivial patch for something that is just working incorrectly. It looks like "nothing is happening" :( It neither accepted nor denied.. If I need to do something to get this fixed in the 2.2 branch I would be glad to help. TIA, Bart -- Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / http://www.hippo.nl --
[jira] Resolved: (MODPYTHON-101) If target handler found but evaluates false, there should still be an error if not silent.
[ http://issues.apache.org/jira/browse/MODPYTHON-101?page=all ]
Graham Dumpleton resolved MODPYTHON-101:
Fix Version: 3.3
Resolution: Fixed
> If target handler found but evaluates false, there should still be an error
> if not silent.
> --
>
> Key: MODPYTHON-101
> URL: http://issues.apache.org/jira/browse/MODPYTHON-101
> Project: mod_python
> Type: Bug
> Components: core
> Versions: 3.2.7, 3.1.4
> Reporter: Graham Dumpleton
> Assignee: Graham Dumpleton
> Fix For: 3.3
>
> If one specifies PythonHandler directive and the target is mistakenly set to
> be something like:
> handler = 0
> handler = None
> handler = False
> handler = []
> handler = {}
> no error is raised.
> As comparison, if one has:
> handler = 1
> you get an error:
> Traceback (most recent call last):
> File
> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/mod_python/apache.py",
> line 309, in HandlerDispatch
> result = object(req)
> TypeError: 'int' object is not callable
> This is because if the target in any way evaluates to false, no attempt is
> made to execute it, but at the same time if the silent flag is not set no
> error is raised either.
> In the case of HandlerDispatch in apache.py, the code currently is:
> # find the object
> object = resolve_object(module, object_str,
> arg=req, silent=hlist.silent)
>
> if object:
>
> # call the object
>
> elif hlist.silent:
> result = DECLINED
>
> It would make more sense that if hlist.silent is not set, that the object,
> whatever it may be should be called. This would ensure that any error
> response is always generated when it can be.
> Thus, instead of just:
> if object:
> it should really be:
> if not hlist.silent or object:
> In the case of ConnectionDispatch() and FilterDispatch(), because silent is
> fixed to "0" in those cases, there should not even be a check of whether
> object evaluates true, it should just be called regardless.
> Thus instead of:
> if object:
> # call the object
> if config.has_key("PythonEnablePdb"):
> result = pdb.runcall(object, conn)
> else:
> result = object(conn)
> it should just be:
> # call the object:
> if config.has_key("PythonEnablePdb"):
> result = pdb.runcall(object, conn)
> else:
> result = object(conn)
> Indent level of following assertion clause in case of ConnectionDispatch()
> and call to filter.flush() in FilterDispatcher() should also be shifted out
> as well as appropriate.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: Joint Release of all branches
On Sun, Apr 23, 2006 at 11:20:59PM -0700, Sander Temme wrote: > It looks like the 2.2.2 RC is the closest to being ready for release, > with the 72 hour window on www.a.o running out Monday night Pacific. > However, I would like to urge holding back the release until the > branches can catch up. Tbh, I'm -0.5 on this. It's complex enough as it is trying to get releases out, and 1.3 hasn't even tagged yet. > For 2.0, we probably should re-roll 2.0.58 with the copyright > statement reversion and take a new vote -1, there's been enough back and forth on this. The current status is that the existing candidate is good for release unless people start reverting their +1's, which so far - has not happened. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
