quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Gallacher <...@jgassociates.ca>
Subject Re: My plans for mod_python changes (260206).
Date Fri, 03 Mar 2006 17:59:50 GMT
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 
python-cvs@httpd.apache.org, 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.


View raw message