On 03/02/2006, at 2:54 PM, Jim Gallacher wrote:
Graham Dumpleton wrote:
To confirm Jim's arithmetic anyway, I say -1 on 3.2.6 as it stands.
As to 3.2.7, I say +1, subject to removal of problematic test case
as already raised and with us at least confirming tests run OK for
version out of SVN p
We probably want to defer until after 3.2.7 (final) is released to have
any serious discussion about what should constitute version 3.3, but
am still curious to know at this point where your interests in 3.3 lie.
Is it simply to help finish up eliminating all these known issues/bugs
or do you ha
Graham Dumpleton wrote:
To confirm Jim's arithmetic anyway, I say -1 on 3.2.6 as it stands.
As to 3.2.7, I say +1, subject to removal of problematic test case
as already raised and with us at least confirming tests run OK for
version out of SVN prior to packaging.
Oh, so *that's* where you sai
Graham Dumpleton wrote:
Jim Gallacher wrote ..
It is because you probably have a prefork/worker MPM.
The test as written will only reliably work for winnt MPM.
Doh! Prefork bites us in the a** yet again. :)
On UNIX boxes
the subsequent requests could be handled by a different child pro
Jim Gallacher wrote ..
> > It is because you probably have a prefork/worker MPM.
> >
> >> The test as written will only reliably work for winnt MPM.
> >
> >
> > Doh! Prefork bites us in the a** yet again. :)
> >
> >> On UNIX boxes
> >> the subsequent requests could be handled by a different c
Jim Gallacher wrote:
Graham Dumpleton wrote:
Jim Gallacher wrote ..
I'm getting a unit test failure.
FAIL: test_publisher_cache (__main__.PerRequestTestCase)
--
Traceback (most recent call last):
File "test.py", line 1836,
Very interesting. I'll only comment on one issue right now.
Daniel J. Popowich wrote ..
> o And...no suprise...I'd like to try to sell mpservlets for
> inclusion in the main distro. No tears if it's not, but I think
> it fills a void and I'd like to make a case for its inclusion.
I con
Graham Dumpleton writes:
> Daniel J. Popowich wrote ..
> > PS
> > If it's not obvious I'm gearing up to get way more involved...I've
> > been waiting (patiently) for 3.2 to be released and jump in with new
> > 3.3 development...I guess I'm chomping at the bit...
>
> We probably want to defer unti
Allow PythonImport to optionally call function in module.
-
Key: MODPYTHON-118
URL: http://issues.apache.org/jira/browse/MODPYTHON-118
Project: mod_python
Type: Wish
Components: core
Versions: 3.3
Daniel J. Popowich wrote ..
> PS
> If it's not obvious I'm gearing up to get way more involved...I've
> been waiting (patiently) for 3.2 to be released and jump in with new
> 3.3 development...I guess I'm chomping at the bit...
We probably want to defer until after 3.2.7 (final) is released to hav
I have a bunch of code I was thinking of contributing to mod_python,
but would like some opinions before doing so (because I don't
know if this is the best place)...
Basically I wrote some utility functions which can be used to
assist with content negotiation; such as parsing the various
Accept-*
I'm getting a unit test failure.
FAIL: test_publisher_cache (__main__.PerRequestTestCase)
--
Traceback (most recent call last):
File "test.py", line 1836, in test_publisher_cache
self.fail(
File "/usr/lib/python2.3/unitte
According to the Apache rules we need three +1 votes. As there are only
4 of us voting the two +0 votes are already enough to kill the proposal.
(I should have done the math this morning. ;) )
I'll commit Grahams' _conn_read fix and generate the 3.2.7 tarball
shortly. I'm also +1 on releasing
On 03/02/2006, at 4:48 AM, Daniel J. Popowich wrote:
My gut says any major release of mod_python be based on one
major.minor release lower than the currently available python. So,
mod_python 3.2 is based on python 2.3; mod_python 3.3 will probably be
based on python 2.4 (because 2.5 will be out
My official vote is eventually -1 for 3.2.6, see the previous
discussion for why I've changed my mind.
However I'm +1 on releasing 3.2.7 without a restrained testing period,
not a long one like for 3.2.6.
Regards,
Nicolas
2006/2/2, Jim Gallacher <[EMAIL PROTECTED]>:
> I know you said no discussi
Jim Gallacher writes:
> Daniel J. Popowich wrote:
> > Regardless, I do not think it is within the scope of mod_python
> > developers to keep users forward-compatible with the underlying python
> > version. Sorry, but IMHO, this is not scalable software engineering.
>
> I'll re-read this paragrap
2006/2/2, Jim Gallacher <[EMAIL PROTECTED]>:
> If we are going to do a 3.2.7, let's just do it. Either spend a couple
> of days debating the merits of 3.2.7 or a couple of days *testing* it. :)
>
> My list for 3.2.7
> connection handler fix so it passes the unit tests
I'll let you pros do that :
Nicolas Lehuen wrote:
We should also agree that if we do do a 3.2.7 what will be fixed in it
and this time set a strict time frame on how long we let it be tested.
Do we leave it at stat.ST_MTIME, or also add the connection handler
fix as well if we are happy with that? Is a "b" designation neede
PythonImport that works for any interpreter.
Key: MODPYTHON-117
URL: http://issues.apache.org/jira/browse/MODPYTHON-117
Project: mod_python
Type: Wish
Components: core
Versions: 3.2
Reporter: Graham Dumplet
I am hereby happy to tell you that by removing the call to enumerate()
in the publisher code, the whole test suite passes on Python 2.2
without any further patch or hack. I've checked in the modification
which this time should not pose any problem since it's pretty basic
and non intrusive.
Regards
On 02/02/2006, at 5:54 PM, Nicolas Lehuen wrote:
Having read your work on Vampire (and its
module importing mechanism) I'm pretty sure it won't be long.
The new importer is actually a complete rewrite and some things
are done quite differently to what was done in Vampire. I have in
effect rew
21 matches
Mail list logo
