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.
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? :-)
That all said, below are the list of JIRA issues I intend to address
in the coming
week and commit changes back into the repository for. As I do get
around to
each I'll assign it to myself in JIRA so everyone knows my progress
and when
I am ready to do a commit will also attach patches for review and
then wait for
a bit for any last minute objections. If any objections can be
expressed early
on based on just the proposal for change, that would be appreciated.
https://issues.apache.org/jira/browse/MODPYTHON-133
req.server.get_config() table object populated wrongly.
https://issues.apache.org/jira/browse/MODPYTHON-134
Setting PythonDebug to Off, doesn't override On setting in
parent scope.
https://issues.apache.org/jira/browse/MODPYTHON-137
Add req.server.get_options() for obtain PythonOption values set
at global level.
https://issues.apache.org/jira/browse/MODPYTHON-104
Allow Python code callouts with mod_include (SSI).
https://issues.apache.org/jira/browse/MODPYTHON-109
Signal handler calling Py_Finalize() when child processes being
killed.
https://issues.apache.org/jira/browse/MODPYTHON-129
HandlerDispatch doesn't treat OK/DECLINED result properly for
all phases.
Of these, main one I am concerned about is any perceived implications of
changes suggested for MODPYTHON-109.
Graham
