Graham Dumpleton wrote:
On 03/03/2006, at 1:55 PM, Jim Gallacher wrote:
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
I haven't been committing in anything yet, I presume you mean JIRA.
No, I meant the subversion commit messages posted to
[EMAIL PROTECTED], for those cases where a Commit-Then-Review
or Lazy Consensus attitude has been adopted.
Anyway, so far I've taken the attitude that I'll post up proposed changes
to JIRA issue for a while. If no one says anything I'll check in the ones
that I believe aren't going to be too controversial. That said, I will
commit
changes for the following over the weekend.
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.
Those were in my TODO list. Have also added the following and will
commit these as well since I don't see any drama with these.
http://issues.apache.org/jira/browse/MODPYTHON-140
util.redirect() returns wrong SERVER_RETURN status value
http://issues.apache.org/jira/browse/MODPYTHON-141
Allow handlers to trigger proxying of requests.
Will defer on the following for the moment, until wider consensus
reached as to
whether new feature or change is okay.
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.
I still haven't started on the following, but will do so over the weekend.
https://issues.apache.org/jira/browse/MODPYTHON-129
HandlerDispatch doesn't treat OK/DECLINED result properly for all
phases.
After that I'll work out what I'll target for the next week or so.
Overall, have made good progress this past week. Will see how long I can
keep this up for. :-)
BTW, as I commit, I will if appropriate mark them as resolved.
More in the way of a general observation rather than on these specific
issues, but I wouldn't necessarily mark things as resolved just on the
basis of the fix being committed. For the big changes at least, I think
we should see some testing on a couple of different platforms. Maybe we
could announce development milestones and ask the community for a round
of testing? Issues would be marked as resolved after each milestone test
cycle. That way we are more likely to catch problems early and hopefully
reduce the time it takes for the next beta cycle. We should do whatever
we can to avoid the 7 months it took to get 3.2 out. (Actually, it was
even longer than that, as Grisha first mentioned a 3.2 release last
spring). Ideally trunk would always be in a stable enough condition that
we could do a release within a month of making a decision.
Jim
