The 3.2.0 release

[Nicolas Lehuen <ni...@gmail.com>]

As you can see on
http://issues.apache.org/jira/secure/BrowseProject.jspa , there are
only two bugs still scheduled for 3.2.0 ; the rest is not scheduled.

Should we schedule all bugs for 3.2.0 and only release it once all the
bugs are released, or could we make an intermediary release ? I'm in
favor of an intermediary release with the bunch of bug fixes that
we've already done.

In this case, can everybody review the remaining bugs on JIRA and
select those they want to be fixed for 3.2.0 ?

Regards,
Nicolas

Re: The 3.2.0 release

[Graham Dumpleton <gr...@dscpl.com.au>]

On 08/06/2005, at 7:19 AM, Jim Gallacher wrote:
> MODPYTHON-37
> Add apache.register_cleanup()
>
>     According to the FAQ entry linked by Graham, this probably can't 
> be done, so change it's status to closed?

Actually, I still believe it can be done, but from memory Grisha 
expressed
reservations at the time about my thinking on how it could be achieved 
so
I didn't pursue it any further at the time.

Not sure my current thoughts on it now are the same as what I pushing
earlier, but at the time the mod_python.c creates the interpreters and
loads the _apache module into each, it has access to the server_rec 
struct
which is effectively what the Python serverobject is in part a wrapper 
for.

As such, with perhaps a bit of initialisation at the time _apache is 
setup
for each interpreter, one could provide a method in _apache which gives 
access
to an instance of a serverobject. Having access to that, one could then 
call
register_cleanup() on it to register the callback.

Graham

Re: The 3.2.0 release

[Jim Gallacher <jg...@sympatico.ca>]

Nicolas Lehuen wrote:
> As you can see on
> http://issues.apache.org/jira/secure/BrowseProject.jspa , there are
> only two bugs still scheduled for 3.2.0 ; the rest is not scheduled.
> 
> Should we schedule all bugs for 3.2.0 and only release it once all the
> bugs are released, or could we make an intermediary release ? I'm in
> favor of an intermediary release with the bunch of bug fixes that
> we've already done.

Personally I'd like to see as many issues resolved as possible, even 
those not scheduled. That being said, the fixes for the issues I suggest 
below (except for MODPYTHON-38) are pretty straight forward. I scan JIRA 
again to see if there are any others that can be readily resolved.

Also, I'd *really* like to hold off on the release until my new session 
handling mechanism can be incorporated. I've been banging away at it for 
a week, trying to track down some strange segfaults. I'll be posting a 
message on this shortly.

> In this case, can everybody review the remaining bugs on JIRA and
> select those they want to be fixed for 3.2.0 ?

Here are the issues I'd like to see resolved before a release:

MODPYTHON-19
Add a section about security in the documentation

     We should at least have some mention about security for this 
release, even if it is not exhaustive. You can assign this one to me if 
you like.

MODPYTHON-37
Add apache.register_cleanup()

     According to the FAQ entry linked by Graham, this probably can't be 
done, so change it's status to closed?

MODPYTHON-38
Passing req.form into psp.PSP().

     It would be nice to resolve the form handling issues in general. I 
don't think a change like this should go in a bug fix (eg 3.2.1). Much 
better to do it now if possible, although this is not trivial.

MODPYTHON-45
Implement a file-based session manager

     This is waiting for docs from me, but I want to add some features 
to the general session handling mechanism first. See the following email.

MODPYTHON-52
path to flex used in compiling mod_python is hard coded

     I have a patch for this that will fix the build on *nix systems. 
The patch does not help the current build in the Windows world where 
configure is not used, but at least it'll take care of some users.

MODPYHON-55
Add a version attribute to the mod_python module

I'd like to reopen this issue and apply the patch I suggested, which 
adds the function static PyObject * server_get_mp_version. This way we 
don't need to worry about parsing the source for the correct version.

MODPYTHON-58
_apache._global_lock results in segfault when index > number of mutexes

     This is a bug, pure and simple and I have the patch. We should 
never ship software that knowingly causes a segfault.

MODPYHON-?? no jira issue yet
There are errors in the documentation where the docs don't match the 
mod_python code.

I have the patches to fix these, and will create a corresponding JIRA 
issue. Not release critical, but we may as well fix them now rather than 
later.

Regards
Jim