You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mod_python-dev@quetz.apache.org by "Gregory (Grisha) Trubetskoy" <gr...@ispol.com> on 2005/07/28 17:02:13 UTC
3.2
I just looked on JIRA, and there are 3 issues marked for 3.2.
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=10640&fixfor=11060
I don't see any of them as show stopping really, IMHO we should be able to
release 3.2 beta as it is now.
Could we have a little vote on this?
Thanks!
Re: 3.2
Posted by Jim Gallacher <jg...@sympatico.ca>.
Gregory (Grisha) Trubetskoy wrote:
>
> I just looked on JIRA, and there are 3 issues marked for 3.2.
>
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=10640&fixfor=11060
>
>
> I don't see any of them as show stopping really, IMHO we should be able
> to release 3.2 beta as it is now.
>
> Could we have a little vote on this?
>
> Thanks!
>
+1
Re: 3.2
Posted by Jim Gallacher <jg...@sympatico.ca>.
Gregory (Grisha) Trubetskoy wrote:
>
> On Thu, 28 Jul 2005, Jim Gallacher wrote:
>
>> I don't want to leave req_get_session in as-is since people may start
>> using it which would make things difficult if the final solution ends
>> up being something completely different. Rather than delete
>> req_get_session() completely I'd like to change it to
>> raise a NotImplemented error. That way there is starting point for 3.3
>> but nobody will depend on it actually being there. Does this seem
>> reasonable?
>
>
> +1
>
> Grisha
>
I've commited this change. get_session implementation will be deferred
to 3.3.
Jim
Re: 3.2
Posted by "Gregory (Grisha) Trubetskoy" <gr...@ispol.com>.
On Thu, 28 Jul 2005, Jim Gallacher wrote:
> I don't want to leave req_get_session in as-is since people may start using
> it which would make things difficult if the final solution ends up being
> something completely different. Rather than delete req_get_session()
> completely I'd like to change it to
> raise a NotImplemented error. That way there is starting point for 3.3 but
> nobody will depend on it actually being there. Does this seem reasonable?
+1
Grisha
Re: 3.2
Posted by Jim Gallacher <jg...@sympatico.ca>.
Nicolas Lehuen wrote:
> Hi,
>
> I've marked #45 as resolved, since the FileSession class has been
> checked in for a while now. We only need a bit of documentation, but a
> few seconds of source browsing can help an adventurous user to see how
> to use FileSession. Now, what should we do about the new
> req.get_session() API ? Is it ready for release now ?
No. Graham has raised some valid concerns about the current
implentation. See http://issues.apache.org/jira/browse/MODPYTHON-59
I haven't had time to address these issues properly, and I'd rather see
it pushed into 3.3 rather than release a half-baked solution in 3.2.
I don't want to leave req_get_session in as-is since people may start
using it which would make things difficult if the final solution ends up
being something completely different. Rather than delete
req_get_session() completely I'd like to change it to
raise a NotImplemented error. That way there is starting point for 3.3
but nobody will depend on it actually being there. Does this seem
reasonable?
Regards,
Jim
Re: 3.2
Posted by dharana <dh...@dharana.net>.
As a non-developer, just as an user:
+1
Nicolas Lehuen wrote:
> OK, +1 for me.
>
> Regards,
> Nicolas
>
> 2005/7/28, Gregory (Grisha) Trubetskoy <grisha@ispol.com
> <ma...@ispol.com>>:
>
>
> On Thu, 28 Jul 2005, Nicolas Lehuen wrote:
>
> > Note that there are 29 unscheduled issues :
> >
> >
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=10640&fixfor=-1
> <http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=10640&fixfor=-1>
> >
> > Maybe some of them should be included in the 3.2 release ?
>
> My inclanation is to just release whatever we have, and mark it as a
> beta
> release. The last "true" release was 3.1.3 in Feb 2004, which makes
> it 18
> months (if my math is correct)....
>
> Grisha
>
>
--
dharana
Re: 3.2
Posted by Nicolas Lehuen <ni...@gmail.com>.
OK, +1 for me.
Regards,
Nicolas
2005/7/28, Gregory (Grisha) Trubetskoy <gr...@ispol.com>:
>
>
> On Thu, 28 Jul 2005, Nicolas Lehuen wrote:
>
> > Note that there are 29 unscheduled issues :
> >
> >
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=10640&fixfor=-1
> >
> > Maybe some of them should be included in the 3.2 release ?
>
> My inclanation is to just release whatever we have, and mark it as a beta
> release. The last "true" release was 3.1.3 in Feb 2004, which makes it 18
> months (if my math is correct)....
>
> Grisha
>
Re: 3.2
Posted by Jim Gallacher <jg...@sympatico.ca>.
Gregory (Grisha) Trubetskoy wrote:
>
> On Thu, 28 Jul 2005, Jim Gallacher wrote:
>
>> I've either commited fixes or have fixes ready for 6 or 8 of those
>> issues. Also there some that don't apply to 3.2 (eg website or mailing
>> list issues). Must run right now but will make a list this evening of
>> issues which can be closed.
>
>
> Do you think you'll be able to create a tgz file? It would really be
> fantastic if someone other than me could do it.
>
> Grisha
>
Yes I can do that. I've already done a couple of dry runs with good
success.
Jim
Re: 3.2
Posted by "Gregory (Grisha) Trubetskoy" <gr...@ispol.com>.
On Thu, 28 Jul 2005, Jim Gallacher wrote:
> I've either commited fixes or have fixes ready for 6 or 8 of those issues.
> Also there some that don't apply to 3.2 (eg website or mailing list issues).
> Must run right now but will make a list this evening of issues which can be
> closed.
Do you think you'll be able to create a tgz file? It would really be
fantastic if someone other than me could do it.
Grisha
Re: 3.2 - resolved issues
Posted by Jim Gallacher <jg...@sympatico.ca>.
Nicolas Lehuen wrote:
Hi Nicolas,
Could you mark these issues as resolved as well?
Potential deadlock in psp cache.
http://issues.apache.org/jira/browse/MODPYTHON-69
Add configure --with-max-locks option to set MAX_LOCKS.
http://issues.apache.org/jira/browse/MODPYTHON-70
(We can create a new issue to add this functionality to setup.py if you
like).
Thanks,
Jim
Re: 3.2
Posted by Jim Gallacher <jg...@sympatico.ca>.
Nicolas,
I should have mentioned that I would like you to mark them as resolved,
but you have anyway, so all is well. :)
Jim
Jim Gallacher wrote:
> Nicolas Lehuen wrote:
>
>> Hi Jim,
>>
>> Do you want me to mark the issues resolved ? Don't you have the rights
>> to do this ? If you don't have the right, then maybe Scott Sanders can
>> give them to you (and to Graham while we're at it...). Scott, are you
>> reading this ?
>
>
> No, I don't have permissions to assign or mark issues. Both would be
> nice. Following Graham's example I'm trying to put more stuff through
> JIRA rather than just committing my changes to subversion. However we
> end up with a large number of issues which are unassigned, which I think
> may gives people the idea that there is not much activity in the project
> which is not the case.
>
> Is Scott out there?
>
> Regards,
> Jim
>
>> Regards,
>> Nicolas
>>
>> 2005/7/29, Jim Gallacher <jg.lists@sympatico.ca
>> <ma...@sympatico.ca>>:
>>
>> Jim Gallacher wrote:
>> > Gregory (Grisha) Trubetskoy wrote:
>> >
>> >>
>> >> On Thu, 28 Jul 2005, Nicolas Lehuen wrote:
>> >>
>> >>> Note that there are 29 unscheduled issues :
>> >>>
>> >>>
>>
>> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=10640&fixfor=-1
>>
>>
>> <http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=10640&fixfor=-1>
>>
>> >>>
>> >>>
>> >>> Maybe some of them should be included in the 3.2 release ?
>> >>
>> >>
>> >>
>> >> My inclanation is to just release whatever we have, and mark it
>> as a
>> >> beta release. The last "true" release was 3.1.3 in Feb 2004,
>> which
>> >> makes it 18 months (if my math is correct)....
>> >>
>> >> Grisha
>> >>
>> >
>> > I've either commited fixes or have fixes ready for 6 or 8 of those
>> > issues. Also there some that don't apply to 3.2 (eg website or
>> mailing
>> > list issues). Must run right now but will make a list this
>> evening of
>> > issues which can be closed.
>> >
>> > Jim
>> >
>>
>> Here is my list. I think you can close all of these JIRA issues
>> except
>> MODPYTHON-52.
>>
>> http://issues.apache.org/jira/browse/MODPYTHON-45
>> Implement a file-based session manager
>> Resolved but waiting for documentation. Working on it now - will
>> commit
>> in the next 12 hours.
>>
>> http://issues.apache.org/jira/browse/MODPYTHON-58
>> _apache._global_lock results in segfault when index > number of
>> mutexes
>> Fix has been commited
>>
>> http://issues.apache.org/jira/browse/MODPYTHON-62
>> local_ip and local_host in connection object returns remote_ip and
>> remote_host instead
>> This issue only applies to 3.1.4. It's already been fixed in 3.2.
>>
>> http://issues.apache.org/jira/browse/MODPYTHON-65
>> 3.2 working version will not install on Mac OS X (10.3.7)
>> Fix has been commited.
>>
>> http://issues.apache.org/jira/browse/MODPYTHON-66
>> <http://issues.apache.org/jira/browse/MODPYTHON-66>
>> install_dso target also tries to install Python code files
>> Fix has been commited.
>>
>> http://issues.apache.org/jira/browse/MODPYTHON-59
>> Add get_session() method to request object
>> Let's defer this to 3.3. I've changed current implementation to
>> raise a
>> NotImplemented error.
>>
>> Related to get_session, I've made a small change to
>> Session.Session().
>> It now checks PythonOption session for the default session type
>> before
>> using the hard coded default. For reasons that escape me I put
>> this in a
>> separate function, create_session(), but it really belongs in
>> Session().
>> This is useful outside of get_session, so I've kept the change for
>> 3.2.
>>
>> Regards,
>> Jim
>>
>>
>
Re: 3.2
Posted by Jim Gallacher <jg...@sympatico.ca>.
Nicolas Lehuen wrote:
> Hi Jim,
>
> Do you want me to mark the issues resolved ? Don't you have the rights
> to do this ? If you don't have the right, then maybe Scott Sanders can
> give them to you (and to Graham while we're at it...). Scott, are you
> reading this ?
No, I don't have permissions to assign or mark issues. Both would be
nice. Following Graham's example I'm trying to put more stuff through
JIRA rather than just committing my changes to subversion. However we
end up with a large number of issues which are unassigned, which I think
may gives people the idea that there is not much activity in the project
which is not the case.
Is Scott out there?
Regards,
Jim
> Regards,
> Nicolas
>
> 2005/7/29, Jim Gallacher <jg.lists@sympatico.ca
> <ma...@sympatico.ca>>:
>
> Jim Gallacher wrote:
> > Gregory (Grisha) Trubetskoy wrote:
> >
> >>
> >> On Thu, 28 Jul 2005, Nicolas Lehuen wrote:
> >>
> >>> Note that there are 29 unscheduled issues :
> >>>
> >>>
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=10640&fixfor=-1
> <http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=10640&fixfor=-1>
> >>>
> >>>
> >>> Maybe some of them should be included in the 3.2 release ?
> >>
> >>
> >>
> >> My inclanation is to just release whatever we have, and mark it
> as a
> >> beta release. The last "true" release was 3.1.3 in Feb 2004, which
> >> makes it 18 months (if my math is correct)....
> >>
> >> Grisha
> >>
> >
> > I've either commited fixes or have fixes ready for 6 or 8 of those
> > issues. Also there some that don't apply to 3.2 (eg website or
> mailing
> > list issues). Must run right now but will make a list this evening of
> > issues which can be closed.
> >
> > Jim
> >
>
> Here is my list. I think you can close all of these JIRA issues except
> MODPYTHON-52.
>
> http://issues.apache.org/jira/browse/MODPYTHON-45
> Implement a file-based session manager
> Resolved but waiting for documentation. Working on it now - will commit
> in the next 12 hours.
>
> http://issues.apache.org/jira/browse/MODPYTHON-58
> _apache._global_lock results in segfault when index > number of mutexes
> Fix has been commited
>
> http://issues.apache.org/jira/browse/MODPYTHON-62
> local_ip and local_host in connection object returns remote_ip and
> remote_host instead
> This issue only applies to 3.1.4. It's already been fixed in 3.2.
>
> http://issues.apache.org/jira/browse/MODPYTHON-65
> 3.2 working version will not install on Mac OS X (10.3.7)
> Fix has been commited.
>
> http://issues.apache.org/jira/browse/MODPYTHON-66
> <http://issues.apache.org/jira/browse/MODPYTHON-66>
> install_dso target also tries to install Python code files
> Fix has been commited.
>
> http://issues.apache.org/jira/browse/MODPYTHON-59
> Add get_session() method to request object
> Let's defer this to 3.3. I've changed current implementation to raise a
> NotImplemented error.
>
> Related to get_session, I've made a small change to Session.Session().
> It now checks PythonOption session for the default session type before
> using the hard coded default. For reasons that escape me I put this in a
> separate function, create_session(), but it really belongs in Session().
> This is useful outside of get_session, so I've kept the change for 3.2.
>
> Regards,
> Jim
>
>
Re: 3.2
Posted by Graham Dumpleton <gr...@dscpl.com.au>.
A prerequisite for full JIRA access is probably going to be sending in
the
ASF committers agreement. I haven't done that as yet and so don't have
SVN
access either. I am hoping that my work load will drop after I take a
holiday in September and I'll be able to finally start taking a more
direct
hands on role and get the committers agreement submitted etc.
On 10/08/2005, at 8:58 PM, Nicolas Lehuen wrote:
> Hi Jim,
>
> Do you want me to mark the issues resolved ? Don't you have the
> rights to do this ? If you don't have the right, then maybe Scott
> Sanders can give them to you (and to Graham while we're at it...).
> Scott, are you reading this ?
>
> Regards,
> Nicolas
>
> 2005/7/29, Jim Gallacher <jg...@sympatico.ca>:
> Jim Gallacher wrote:
> > Gregory (Grisha) Trubetskoy wrote:
> >
> >>
> >> On Thu, 28 Jul 2005, Nicolas Lehuen wrote:
> >>
> >>> Note that there are 29 unscheduled issues :
> >>>
> >>>
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?
> reset=true&mode=hide&sorter/order=DESC&sorter/
> field=priority&resolutionIds=-1&pid=10640&fixfor=-1
> >>>
> >>>
> >>> Maybe some of them should be included in the 3.2 release ?
> >>
> >>
> >>
> >> My inclanation is to just release whatever we have, and mark it as a
> >> beta release. The last "true" release was 3.1.3 in Feb 2004, which
> >> makes it 18 months (if my math is correct)....
> >>
> >> Grisha
> >>
> >
> > I've either commited fixes or have fixes ready for 6 or 8 of those
> > issues. Also there some that don't apply to 3.2 (eg website or
> mailing
> > list issues). Must run right now but will make a list this evening of
> > issues which can be closed.
> >
> > Jim
> >
>
> Here is my list. I think you can close all of these JIRA issues except
> MODPYTHON-52.
>
> http://issues.apache.org/jira/browse/MODPYTHON-45
> Implement a file-based session manager
> Resolved but waiting for documentation. Working on it now - will commit
> in the next 12 hours.
>
> http://issues.apache.org/jira/browse/MODPYTHON-58
> _apache._global_lock results in segfault when index > number of mutexes
> Fix has been commited
>
> http://issues.apache.org/jira/browse/MODPYTHON-62
> local_ip and local_host in connection object returns remote_ip and
> remote_host instead
> This issue only applies to 3.1.4. It's already been fixed in 3.2.
>
> http://issues.apache.org/jira/browse/MODPYTHON-65
> 3.2 working version will not install on Mac OS X (10.3.7)
> Fix has been commited.
>
> http://issues.apache.org/jira/browse/MODPYTHON-66
> install_dso target also tries to install Python code files
> Fix has been commited.
>
> http://issues.apache.org/jira/browse/MODPYTHON-59
> Add get_session() method to request object
> Let's defer this to 3.3. I've changed current implementation to raise a
> NotImplemented error.
>
> Related to get_session, I've made a small change to Session.Session().
> It now checks PythonOption session for the default session type before
> using the hard coded default. For reasons that escape me I put this in
> a
> separate function, create_session(), but it really belongs in
> Session().
> This is useful outside of get_session, so I've kept the change for 3.2.
>
> Regards,
> Jim
>
Re: 3.2
Posted by Nicolas Lehuen <ni...@gmail.com>.
Hi Jim,
Do you want me to mark the issues resolved ? Don't you have the rights to do
this ? If you don't have the right, then maybe Scott Sanders can give them
to you (and to Graham while we're at it...). Scott, are you reading this ?
Regards,
Nicolas
2005/7/29, Jim Gallacher <jg...@sympatico.ca>:
>
> Jim Gallacher wrote:
> > Gregory (Grisha) Trubetskoy wrote:
> >
> >>
> >> On Thu, 28 Jul 2005, Nicolas Lehuen wrote:
> >>
> >>> Note that there are 29 unscheduled issues :
> >>>
> >>>
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=10640&fixfor=-1
> >>>
> >>>
> >>> Maybe some of them should be included in the 3.2 release ?
> >>
> >>
> >>
> >> My inclanation is to just release whatever we have, and mark it as a
> >> beta release. The last "true" release was 3.1.3 in Feb 2004, which
> >> makes it 18 months (if my math is correct)....
> >>
> >> Grisha
> >>
> >
> > I've either commited fixes or have fixes ready for 6 or 8 of those
> > issues. Also there some that don't apply to 3.2 (eg website or mailing
> > list issues). Must run right now but will make a list this evening of
> > issues which can be closed.
> >
> > Jim
> >
>
> Here is my list. I think you can close all of these JIRA issues except
> MODPYTHON-52.
>
> http://issues.apache.org/jira/browse/MODPYTHON-45
> Implement a file-based session manager
> Resolved but waiting for documentation. Working on it now - will commit
> in the next 12 hours.
>
> http://issues.apache.org/jira/browse/MODPYTHON-58
> _apache._global_lock results in segfault when index > number of mutexes
> Fix has been commited
>
> http://issues.apache.org/jira/browse/MODPYTHON-62
> local_ip and local_host in connection object returns remote_ip and
> remote_host instead
> This issue only applies to 3.1.4. It's already been fixed in 3.2.
>
> http://issues.apache.org/jira/browse/MODPYTHON-65
> 3.2 working version will not install on Mac OS X (10.3.7)
> Fix has been commited.
>
> http://issues.apache.org/jira/browse/MODPYTHON-66
> install_dso target also tries to install Python code files
> Fix has been commited.
>
> http://issues.apache.org/jira/browse/MODPYTHON-59
> Add get_session() method to request object
> Let's defer this to 3.3. I've changed current implementation to raise a
> NotImplemented error.
>
> Related to get_session, I've made a small change to Session.Session().
> It now checks PythonOption session for the default session type before
> using the hard coded default. For reasons that escape me I put this in a
> separate function, create_session(), but it really belongs in Session().
> This is useful outside of get_session, so I've kept the change for 3.2.
>
> Regards,
> Jim
>
Re: 3.2
Posted by Nicolas Lehuen <ni...@gmail.com>.
Hi Graham,
Apart from the fact that it is a third way to import modules, I don't see
any problem with the new importing system, as it fixes a lot of bugs while
not touching anything on the apache.import_module side. We have agreed, I
think, that we should not make mod_python.publisher.get_page() public, so
that we don't confuse people needlessly. In fact I've just commented it out
of the source code.
The only problem that the new importing introduces, is that if you use
apache.import_module to import a published module, you get another module
instance than the one mod_python.publisher uses (because the publisher has
his own module cache, distinct from sys.modules).
This means that you cannot properly share data from a published module if
the module which needs the data uses apache.import_module. That's why I
introduced mod_python.publisher.get_page(). But that was a bad idea, since
it introduced a third way to import module, on top of the standard import
keyword and the apache.import_module() function.
Then again, this is a pretty far corner case, which would be annoying only
for threaded MPM for people who have the very bad idea to use published
modules as repositories for shared application data (whereas such data
should be stored in statically loaded modules for now, until
apache.import_module works properly). For any other way to use mod_python,
the new publisher system is perfectly usable AND solves a lot of annoying
problems.
I totally agree that all this is sub-optimal and that we should have a major
overhaul of the importing system, along the guidelines you gave in your
excellent article. But for the 3.2 release, I really think we can get half
way to a correct system by keeping the current apache.import_module and
using the new mod_python.publisher importing system. Let's do the complete
right thing for the 3.3 release.
In any case, reverting mod_python.publisher back to using
apache.import_module is quite easy, so if you guys want me to do it, no
problem, I'll do it.
Regards,
Nicolas
2005/8/10, Graham Dumpleton <gr...@dscpl.com.au>:
>
>
> On 06/08/2005, at 12:02 AM, Gregory (Grisha) Trubetskoy wrote:
>
> >
> > Just thought I'd ask if we're making any progress towards a 3.2
> > tarball to test. No pressure, just curious :-)
>
> What I would like to know is what is going to happen in respect of the
> changes to the module importer for mod_python.publisher.
>
> I accept that it may solve some of the module importer problems as they
> apply to mod_python.publisher, but as I raised as an issue once before
> it introduces yet another way of modules being imported. This means you
> have the "import" statement, "apache.import_module()" and now
> "mod_python.publisher.get_page()". This could cause a lot of confusion
> and result in even more questions on the mailing list about import
> problems with there being no simple answer.
>
> The last time I raised this there was some support for deferring any
> changes to module importing to the version after 3.2. This was in part
> to avoid introducing a solution which would probably get discarded with
> the next version if "apache.import_module()" were to be fixed properly.
> Yes it meant persisting with the problems of "apache.import_module()"
> for a while more, but at least the issues are known.
>
> Anyway, the current mod_python.publisher code is still using this new
> module importer.
>
> Can some one say definitively what the plans are in this area.
>
> Graham
>
>
Re: 3.2
Posted by Graham Dumpleton <gr...@dscpl.com.au>.
On 06/08/2005, at 12:02 AM, Gregory (Grisha) Trubetskoy wrote:
>
> Just thought I'd ask if we're making any progress towards a 3.2
> tarball to test. No pressure, just curious :-)
What I would like to know is what is going to happen in respect of the
changes to the module importer for mod_python.publisher.
I accept that it may solve some of the module importer problems as they
apply to mod_python.publisher, but as I raised as an issue once before
it introduces yet another way of modules being imported. This means you
have the "import" statement, "apache.import_module()" and now
"mod_python.publisher.get_page()". This could cause a lot of confusion
and result in even more questions on the mailing list about import
problems with there being no simple answer.
The last time I raised this there was some support for deferring any
changes to module importing to the version after 3.2. This was in part
to avoid introducing a solution which would probably get discarded with
the next version if "apache.import_module()" were to be fixed properly.
Yes it meant persisting with the problems of "apache.import_module()"
for a while more, but at least the issues are known.
Anyway, the current mod_python.publisher code is still using this new
module importer.
Can some one say definitively what the plans are in this area.
Graham
Re: 3.2
Posted by "Gregory (Grisha) Trubetskoy" <gr...@ispol.com>.
Just thought I'd ask if we're making any progress towards a 3.2 tarball to
test. No pressure, just curious :-)
Grisha
Re: 3.2
Posted by Jim Gallacher <jg...@sympatico.ca>.
Jim Gallacher wrote:
> Jim Gallacher wrote:
>
>> Gregory (Grisha) Trubetskoy wrote:
>>
>>>
>>> On Thu, 28 Jul 2005, Nicolas Lehuen wrote:
>>>
>>>> Note that there are 29 unscheduled issues :
>>>>
>>>> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=10640&fixfor=-1
>>>>
>>>>
>>>> Maybe some of them should be included in the 3.2 release ?
>>>
>>>
>>>
>>>
>>> My inclanation is to just release whatever we have, and mark it as a
>>> beta release. The last "true" release was 3.1.3 in Feb 2004, which
>>> makes it 18 months (if my math is correct)....
>>>
>>> Grisha
>>>
>>
>> I've either commited fixes or have fixes ready for 6 or 8 of those
>> issues. Also there some that don't apply to 3.2 (eg website or mailing
>> list issues). Must run right now but will make a list this evening of
>> issues which can be closed.
>>
>> Jim
>>
>
> Here is my list. I think you can close all of these JIRA issues except
> MODPYTHON-52.
That should read:
"Here is my list. I think you can close all of these JIRA issues except
MODPYTHON-59."
Not sure how *that* typo crept in. 2 is nowhere near 9 on the keyboard.
Jim
>
> http://issues.apache.org/jira/browse/MODPYTHON-45
> Implement a file-based session manager
> Resolved but waiting for documentation. Working on it now - will commit
> in the next 12 hours.
>
> http://issues.apache.org/jira/browse/MODPYTHON-58
> _apache._global_lock results in segfault when index > number of mutexes
> Fix has been commited
>
> http://issues.apache.org/jira/browse/MODPYTHON-62
> local_ip and local_host in connection object returns remote_ip and
> remote_host instead
> This issue only applies to 3.1.4. It's already been fixed in 3.2.
>
> http://issues.apache.org/jira/browse/MODPYTHON-65
> 3.2 working version will not install on Mac OS X (10.3.7)
> Fix has been commited.
>
> http://issues.apache.org/jira/browse/MODPYTHON-66
> install_dso target also tries to install Python code files
> Fix has been commited.
>
> http://issues.apache.org/jira/browse/MODPYTHON-59
> Add get_session() method to request object
> Let's defer this to 3.3. I've changed current implementation to raise a
> NotImplemented error.
>
> Related to get_session, I've made a small change to Session.Session().
> It now checks PythonOption session for the default session type before
> using the hard coded default. For reasons that escape me I put this in a
> separate function, create_session(), but it really belongs in Session().
> This is useful outside of get_session, so I've kept the change for 3.2.
>
> Regards,
> Jim
>
Re: 3.2
Posted by Jim Gallacher <jg...@sympatico.ca>.
Jim Gallacher wrote:
> Gregory (Grisha) Trubetskoy wrote:
>
>>
>> On Thu, 28 Jul 2005, Nicolas Lehuen wrote:
>>
>>> Note that there are 29 unscheduled issues :
>>>
>>> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=10640&fixfor=-1
>>>
>>>
>>> Maybe some of them should be included in the 3.2 release ?
>>
>>
>>
>> My inclanation is to just release whatever we have, and mark it as a
>> beta release. The last "true" release was 3.1.3 in Feb 2004, which
>> makes it 18 months (if my math is correct)....
>>
>> Grisha
>>
>
> I've either commited fixes or have fixes ready for 6 or 8 of those
> issues. Also there some that don't apply to 3.2 (eg website or mailing
> list issues). Must run right now but will make a list this evening of
> issues which can be closed.
>
> Jim
>
Here is my list. I think you can close all of these JIRA issues except
MODPYTHON-52.
http://issues.apache.org/jira/browse/MODPYTHON-45
Implement a file-based session manager
Resolved but waiting for documentation. Working on it now - will commit
in the next 12 hours.
http://issues.apache.org/jira/browse/MODPYTHON-58
_apache._global_lock results in segfault when index > number of mutexes
Fix has been commited
http://issues.apache.org/jira/browse/MODPYTHON-62
local_ip and local_host in connection object returns remote_ip and
remote_host instead
This issue only applies to 3.1.4. It's already been fixed in 3.2.
http://issues.apache.org/jira/browse/MODPYTHON-65
3.2 working version will not install on Mac OS X (10.3.7)
Fix has been commited.
http://issues.apache.org/jira/browse/MODPYTHON-66
install_dso target also tries to install Python code files
Fix has been commited.
http://issues.apache.org/jira/browse/MODPYTHON-59
Add get_session() method to request object
Let's defer this to 3.3. I've changed current implementation to raise a
NotImplemented error.
Related to get_session, I've made a small change to Session.Session().
It now checks PythonOption session for the default session type before
using the hard coded default. For reasons that escape me I put this in a
separate function, create_session(), but it really belongs in Session().
This is useful outside of get_session, so I've kept the change for 3.2.
Regards,
Jim
Re: 3.2
Posted by Jim Gallacher <jg...@sympatico.ca>.
Gregory (Grisha) Trubetskoy wrote:
>
> On Thu, 28 Jul 2005, Nicolas Lehuen wrote:
>
>> Note that there are 29 unscheduled issues :
>>
>> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=10640&fixfor=-1
>>
>>
>> Maybe some of them should be included in the 3.2 release ?
>
>
> My inclanation is to just release whatever we have, and mark it as a
> beta release. The last "true" release was 3.1.3 in Feb 2004, which makes
> it 18 months (if my math is correct)....
>
> Grisha
>
I've either commited fixes or have fixes ready for 6 or 8 of those
issues. Also there some that don't apply to 3.2 (eg website or mailing
list issues). Must run right now but will make a list this evening of
issues which can be closed.
Jim
Re: 3.2
Posted by "Gregory (Grisha) Trubetskoy" <gr...@ispol.com>.
On Thu, 28 Jul 2005, Nicolas Lehuen wrote:
> Note that there are 29 unscheduled issues :
>
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=10640&fixfor=-1
>
> Maybe some of them should be included in the 3.2 release ?
My inclanation is to just release whatever we have, and mark it as a beta
release. The last "true" release was 3.1.3 in Feb 2004, which makes it 18
months (if my math is correct)....
Grisha
Re: 3.2
Posted by Nicolas Lehuen <ni...@gmail.com>.
Note that there are 29 unscheduled issues :
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=10640&fixfor=-1
Maybe some of them should be included in the 3.2 release ?
Regards,
Nicolas
2005/7/28, Nicolas Lehuen <ni...@gmail.com>:
>
> Hi,
>
> I've marked #45 as resolved, since the FileSession class has been checked
> in for a while now. We only need a bit of documentation, but a few seconds
> of source browsing can help an adventurous user to see how to use
> FileSession. Now, what should we do about the new req.get_session() API ?
> Is it ready for release now ?
>
> This leaves use with #8 and #54, which are both related to importing
> issues. Therefore I suggest we move those issues to mod_python 3.3 and try
> to release 3.2 ASAP... A lot of bug fixes have been waiting 9 months or so
> to be fixed "officially".
>
> Regards,
> Nicolas
>
> 2005/7/28, Gregory (Grisha) Trubetskoy <gr...@ispol.com>:
> >
> >
> > I just looked on JIRA, and there are 3 issues marked for 3.2.
> >
> >
> > http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=10640&fixfor=11060
> >
> > I don't see any of them as show stopping really, IMHO we should be able
> > to
> > release 3.2 beta as it is now.
> >
> > Could we have a little vote on this?
> >
> > Thanks!
> >
>
>
Re: 3.2
Posted by Nicolas Lehuen <ni...@gmail.com>.
Hi,
I've marked #45 as resolved, since the FileSession class has been checked in
for a while now. We only need a bit of documentation, but a few seconds of
source browsing can help an adventurous user to see how to use FileSession.
Now, what should we do about the new req.get_session() API ? Is it ready for
release now ?
This leaves use with #8 and #54, which are both related to importing issues.
Therefore I suggest we move those issues to mod_python 3.3 and try to
release 3.2 ASAP... A lot of bug fixes have been waiting 9 months or so to
be fixed "officially".
Regards,
Nicolas
2005/7/28, Gregory (Grisha) Trubetskoy <gr...@ispol.com>:
>
>
> I just looked on JIRA, and there are 3 issues marked for 3.2.
>
>
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=10640&fixfor=11060
>
> I don't see any of them as show stopping really, IMHO we should be able to
> release 3.2 beta as it is now.
>
> Could we have a little vote on this?
>
> Thanks!
>