Graham Dumpleton wrote:
One of the problems when I am looking at making changes to mod_python
is knowing that there is some consensus that changes are a good thing, or
at least that there is no objection.
I feel the same way. Let's establish some policy. I'll start a separate
thread for that discussion as I just want to address your specific plans
here.
So far if a change was trivial, I would commit it without consultation.
I have
also committed some changes which were non trivial but which did not
overlap with existing functionality and have been documented on JIRA for
some time. Other cases I will try and get a response out of list
members as
to whether it is a good idea before proceeding, this may be in the form of
a general discussion or by posting possible patches against JIRA issue.
This has sort of been working okay, but doing it in an ad-hoc manner does
make it a bit harder for me to plan ahead as to what issues in JIRA I am
going to work on next, especially where one change may depend on sorting
another issue out first.
Now that I have got developer access to JIRA and can assign/resolve issues
etc, I can better indicate what issues I am currently looking at. I
thought though
that it may also be a good idea if I regularly post an email to the
list indicating
what batch of issues I would be intending to look at in the coming week or
so. If I do this, I feel that the warning may give time for people to
have a quick
look at the issues and comment on the issue or raise an objection to the
proposed changes because of problems it may cause, before I actually start
proper on dealing with it.
Overall I feel that this will make me more productive and allow me to get
through the issues quicker, as I will not at the last moment just prior
to doing
a commit be waiting for some sort of consensus as whether it was a good
change to make in the first place.
Does this sound helpful, or does everyone just trust that I am not going
to screw things up? :-)
Hopefully people are reviewing the changes on the python-cvs
That all said, below are the list of JIRA issues I intend to address in
the coming
week
https://issues.apache.org/jira/browse/MODPYTHON-133
req.server.get_config() table object populated wrongly.
+1
Unit tests pass on Debian sid for the applied patch.
https://issues.apache.org/jira/browse/MODPYTHON-134
Setting PythonDebug to Off, doesn't override On setting in parent
scope.
+1
I think your concern about user code checking *only* for the existence
of PythonDebug is misplaced. That code is broken if it's not checking
the actual value of PythonDebug.
https://issues.apache.org/jira/browse/MODPYTHON-137
Add req.server.get_options() for obtain PythonOption values set at
global level.
+1
Unit tests pass on Debian sid for the applied patch.
Once this is commited I'll work on runtime configuration
issues such as making the mutex directory configurable
(http://issues.apache.org/jira/browse/MODPYTHON-131) and changing the
number of mutex locks on Apache startup.
https://issues.apache.org/jira/browse/MODPYTHON-104
Allow Python code callouts with mod_include (SSI).
The unit test fails for the applied patch. It looks like it's missing
LoadModule in the config section. I've attached a patch. I'd attach it
to the issue, but JIRA is down right... again. :(
Since this is a new feature I wonder if we should have a vote to see if
everyone agrees it should be incorporated? Do we have a policy for
adding features, other than committing and then seeing if Grisha gets
upset? ;)
FWIW, I'm +1
https://issues.apache.org/jira/browse/MODPYTHON-109
Signal handler calling Py_Finalize() when child processes being
killed.
+1
I have the same concerns as you with this one (ie deprecating
server.register_cleanup), but are there really any other choices?
https://issues.apache.org/jira/browse/MODPYTHON-129
HandlerDispatch doesn't treat OK/DECLINED result properly for all
phases.
+1
Jim
--- test/test.py.orig 2006-03-02 21:00:33.000000000 -0500
+++ test/test.py 2006-03-02 21:01:57.000000000 -0500
@@ -13,7 +13,7 @@
# implied. See the License for the specific language governing
# permissions and limitations under the License.
#
- # $Id: test.py 381031 2006-02-26 00:15:41Z grahamd $
+ # $Id: test.py 381031M 2006-03-03 00:16:34Z (local) $
#
"""
@@ -303,6 +303,9 @@
IfModule("!mod_dir.c",
LoadModule("dir_module %s" %
quoteIfSpace(os.path.join(modpath,
"mod_dir.so")))),
+ IfModule("!mod_include.c",
+ LoadModule("include_module %s" %
+ quoteIfSpace(os.path.join(modpath,
"mod_include.so")))),
ServerRoot(SERVER_ROOT),
ErrorLog("logs/error_log"),
LogLevel("debug"),
