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 02:55:17 GMT
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



Mime
View raw message