[
http://issues.apache.org/jira/browse/MODPYTHON-124?page=comments#action_12366957
]
Graham Dumpleton commented on MODPYTHON-124:
Changes to add req.auth_name(), req.auth_type() and make req.ap_auth_type
writable commited into mod_python SVN
Graham,
I don't think it's necessary to add an additional JIRA comment when you
commit some code. JIRA will pickup the svn commit as long as the issue
number is mentioned in the svn commit message. People can subscribe to
python-cvs if they want notification of the commits.
This should save
Yes, this test seems to be broken. I'll create a JIRA issue for it.
We need unit tests for the unit tests. :)
Jim
For my WTF moment, have a look at test_req_get_basic_auth_pw in the
test suite. I guess it is supposed to be test req.get_basic_auth_pw (), but
that function isn't even mentioned
Now that 3.2.7 is out, should we be changing the status resolved issues
to closed in JIRA.
Jim
Jim Gallacher wrote:
Now that 3.2.7 is out, should we be changing the status resolved issues
to closed in JIRA.
Other JIRA thoughts:
Should we have a unit test component for bugs in the actual unit test
code?
Since we plan on having 3.2.x bugfix releases, should create new JIRA
versions
I already fixed the test and checked it in. :-)
On 20/02/2006, at 5:15 AM, Jim Gallacher wrote:
Yes, this test seems to be broken. I'll create a JIRA issue for it.
We need unit tests for the unit tests. :)
Jim
For my WTF moment, have a look at test_req_get_basic_auth_pw in the
test suite.
+1 Debian sid, apache 2.0.55 mpm-prefork, python 2.3.5
Jim Gallacher wrote ..
Jim Gallacher wrote:
Now that 3.2.7 is out, should we be changing the status resolved issues
to closed in JIRA.
If that is what closed implies. Is there somewhere which states what we
should interprete the different status as meaning? I don't recollect seeing
anything
Graham Dumpleton wrote:
Jim Gallacher wrote ..
Jim Gallacher wrote:
Now that 3.2.7 is out, should we be changing the status resolved issues
to closed in JIRA.
If that is what closed implies. Is there somewhere which states what we
should interprete the different status as meaning? I don't
Graham Dumpleton wrote:
Jim Gallacher wrote ..
Graham,
I don't think it's necessary to add an additional JIRA comment when you
commit some code. JIRA will pickup the svn commit as long as the issue
number is mentioned in the svn commit message. People can subscribe to
python-cvs if they want
Jim Gallacher wrote ..
Other JIRA thoughts:
Should we have a unit test component for bugs in the actual unit test
code?
Since we plan on having 3.2.x bugfix releases, should create new JIRA
versions starting with 3.2.7?
No harm in doing so. Probably would only be used if reported
Jim Gallacher wrote ..
All very interesting, except that JIRA does record the svn commit info,
and with great detail. It just doesn't treat the commit as a comment.
For example:
http://issues.apache.org/jira/browse/MODPYTHON-124?page=all
Personally I think the Subversion commit
Graham Dumpleton wrote:
Jim Gallacher wrote ..
All very interesting, except that JIRA does record the svn commit info,
and with great detail. It just doesn't treat the commit as a comment.
For example:
http://issues.apache.org/jira/browse/MODPYTHON-124?page=all
Personally I think the
+1 FreeBSD 6.0, apache 2.0.55 mpm-prefork, python 2.4.2
Jim Gallacher wrote ..
I don't have alot more to say on these last 2 emails. I think you are on
the right path here.
Okay, I think I have a good plan now.
To summarise the whole issue, the way Apache treats multiple handlers in
a single phase for non content handler phases is as follows:
There is still trouble with the FieldStorage class. Looks like this one is not
really fixed:
http://issues.apache.org/jira/browse/MODPYTHON-40
See for a counter example:
http://modpython.org/pipermail/mod_python/2006-February/020248.html
(remove the import fmt)
It fails with the following
16 matches
Mail list logo
