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 Jim Gallacher <ji...@jgassociates.ca> on 2006/03/14 02:23:21 UTC
mod_python roadmap
I find I work more effectively when I have deadlines to worry about
(being a procrastinator by nature), so I thought I'd propose the
following roadmap.
Mar 20: 3.3-dev - snapshot for testing
Apr 1: 3.2.9 - bugfix release
May 1: 3.3-dev - snapshot for testing
Jun 15: 3.3-dev - snapshot for testing
Jul 15: 3.3 - feature freeze
Aug 1: 3.3.0 - first 3.3 beta
- branches/3.3.x created
- work on trunk resumes
- beta cycle proceeds independent of dev work
Sep 15: 3.3.y - 3.3 final released (hopefully)
For the development snapshots I'd just roll a tarball from trunk and
make a call to the community for testing help. Hopefully we'll catch new
bugs and regressions early so that the actual beta cycle will be much
shorter. There would be *no* freeze during the snapshot tests. Work on
trunk can continue while we wait for the test feedback.
Graham suggested a number of issues when we were considering a 3.2.8
bugfix release. In the end 3.2.8 was a security release, but the rest of
the list is still valid.
MODPYTHON-77
The Simplified GIL Aquisition patches.
Fixed in trunk, Jim will backport.
MODPYTHON-78
Apache 2.2 patches.
Fixed in trunk and backported to branches/3.2.x
MODPYTHON-94
Support for optional mod_ssl functions on request object.
Fixed in trunk, Jim will backport.
MODPYTHON-119
DBM Session test patches.
Fixed in trunk and backported to branches/3.2.x
MODPYTHON-122
Bash 3.1.X configure patches.
Fixed in trunk and backported to branches/3.2.x
MODPYTHON-131
Make mutex directory configurable.
Fixed in trunk, Jim will backport
This fix depends on MODPYTHON-137.
New issues to consider for inclusion:
MODPYTHON-137
Add req.server.get_options() for obtain PythonOption values set at
global level.
Fixed in trunk.
MODPYTHON-145
Make number of mutex locks configurable at apache startup
Fixed in trunk.
This issue touches the same code as MODPYTHON-131. Backporting
131 will be easier if this one is included.
Any other issues for a 3.2.9 release?
(This is where Mike L. should advocate for MODPYTHON-93 - Improved
FieldStorage. ;) )
Jim
Re: mod_python roadmap
Posted by Mike Looijmans <nl...@natlab.research.philips.com>.
...
> Any other issues for a 3.2.9 release?
> (This is where Mike L. should advocate for MODPYTHON-93 - Improved
> FieldStorage. ;) )
Eh, yeah, I have a suggestion:
MODPYTHON-93 - Improved FieldStorage
- Stop putting simple key/value pairs into StringIO objects, put them simple str objects
- Use a dictionary for fields
- Allow any file-like object ('write' method) to be used in a make_file callback
(all the coding is already done)
Mike Looijmans
Philips Natlab / Topic Automation
Re: New module importer. Was: Re: mod_python roadmap
Posted by Nicolas Lehuen <ni...@lehuen.com>.
If the new importer isn't on by default, I don't see any reason why
you should not commit it to subversion, quite the contrary.
Therefore I'm +1 on the subject.
Regards,
Nicolas
2006/3/19, Graham Dumpleton <gr...@dscpl.com.au>:
>
> On 14/03/2006, at 12:23 PM, Jim Gallacher wrote:
>
> > I find I work more effectively when I have deadlines to worry about
> > (being a procrastinator by nature), so I thought I'd propose the
> > following roadmap.
> >
> > Mar 20: 3.3-dev - snapshot for testing
> > Apr 1: 3.2.9 - bugfix release
> > May 1: 3.3-dev - snapshot for testing
> > Jun 15: 3.3-dev - snapshot for testing
> > Jul 15: 3.3 - feature freeze
> > Aug 1: 3.3.0 - first 3.3 beta
> > - branches/3.3.x created
> > - work on trunk resumes
> > - beta cycle proceeds independent of dev work
> > Sep 15: 3.3.y - 3.3 final released (hopefully)
> >
> > For the development snapshots I'd just roll a tarball from trunk and
> > make a call to the community for testing help. Hopefully we'll catch
> > new bugs and regressions early so that the actual beta cycle will be
> > much shorter. There would be *no* freeze during the snapshot tests.
> > Work on trunk can continue while we wait for the test feedback.
>
> With the plan being to roll a tar ball on the 20th March, do people want
> me to incorporate the new module importer or not, such that it will be
> included in this snapshot and be available for testing?
>
> For background on the new importer see:
>
> https://issues.apache.org/jira/browse/MODPYTHON-143
>
> and follow links given there to articles I have written or started
> writing and all the JIRA issues.
>
> The code for this is all ready, it just needs to be committed into the
> subversion repository.
>
> Note that just because the code would be part of the source code does
> not mean it will be used. Specifically, the code has been set up at the
> moment so the existing importer will still be used unless you explicitly
> configure mod_python to use the new importer. If you want to try the new
> module importer, you will be able to enable it for all Python
> interpreter instances created, or selected ones. Only after sufficient
> testing and tweaking as necessary, and after it has been deemed an
> acceptable solution would it be properly integrated into mod_python as
> the default. If people feel it isn't acceptable, it would be stripped
> out of code and someone else can have a go with coming up with a
> better alternative.
>
> Graham
>
>
>
>
>
>
>
Re: New module importer. Was: Re: mod_python roadmap
Posted by Jim Gallacher <jp...@jgassociates.ca>.
+1
Commit it. The point of the snapshot is encourage testing to catch
problems earlier in the development cylce.
Jim
Graham Dumpleton wrote:
>
> On 14/03/2006, at 12:23 PM, Jim Gallacher wrote:
>
>> I find I work more effectively when I have deadlines to worry about
>> (being a procrastinator by nature), so I thought I'd propose the
>> following roadmap.
>>
>> Mar 20: 3.3-dev - snapshot for testing
>> Apr 1: 3.2.9 - bugfix release
>> May 1: 3.3-dev - snapshot for testing
>> Jun 15: 3.3-dev - snapshot for testing
>> Jul 15: 3.3 - feature freeze
>> Aug 1: 3.3.0 - first 3.3 beta
>> - branches/3.3.x created
>> - work on trunk resumes
>> - beta cycle proceeds independent of dev work
>> Sep 15: 3.3.y - 3.3 final released (hopefully)
>>
>> For the development snapshots I'd just roll a tarball from trunk and
>> make a call to the community for testing help. Hopefully we'll catch
>> new bugs and regressions early so that the actual beta cycle will be
>> much shorter. There would be *no* freeze during the snapshot tests.
>> Work on trunk can continue while we wait for the test feedback.
>
>
> With the plan being to roll a tar ball on the 20th March, do people want
> me to incorporate the new module importer or not, such that it will be
> included in this snapshot and be available for testing?
>
> For background on the new importer see:
>
> https://issues.apache.org/jira/browse/MODPYTHON-143
>
> and follow links given there to articles I have written or started
> writing and all the JIRA issues.
>
> The code for this is all ready, it just needs to be committed into the
> subversion repository.
>
> Note that just because the code would be part of the source code does
> not mean it will be used. Specifically, the code has been set up at the
> moment so the existing importer will still be used unless you explicitly
> configure mod_python to use the new importer. If you want to try the new
> module importer, you will be able to enable it for all Python
> interpreter instances created, or selected ones. Only after sufficient
> testing and tweaking as necessary, and after it has been deemed an
> acceptable solution would it be properly integrated into mod_python as
> the default. If people feel it isn't acceptable, it would be stripped
> out of code and someone else can have a go with coming up with a
> better alternative.
>
> Graham
New module importer. Was: Re: mod_python roadmap
Posted by Graham Dumpleton <gr...@dscpl.com.au>.
On 14/03/2006, at 12:23 PM, Jim Gallacher wrote:
> I find I work more effectively when I have deadlines to worry about
> (being a procrastinator by nature), so I thought I'd propose the
> following roadmap.
>
> Mar 20: 3.3-dev - snapshot for testing
> Apr 1: 3.2.9 - bugfix release
> May 1: 3.3-dev - snapshot for testing
> Jun 15: 3.3-dev - snapshot for testing
> Jul 15: 3.3 - feature freeze
> Aug 1: 3.3.0 - first 3.3 beta
> - branches/3.3.x created
> - work on trunk resumes
> - beta cycle proceeds independent of dev work
> Sep 15: 3.3.y - 3.3 final released (hopefully)
>
> For the development snapshots I'd just roll a tarball from trunk and
> make a call to the community for testing help. Hopefully we'll catch
> new bugs and regressions early so that the actual beta cycle will be
> much shorter. There would be *no* freeze during the snapshot tests.
> Work on trunk can continue while we wait for the test feedback.
With the plan being to roll a tar ball on the 20th March, do people want
me to incorporate the new module importer or not, such that it will be
included in this snapshot and be available for testing?
For background on the new importer see:
https://issues.apache.org/jira/browse/MODPYTHON-143
and follow links given there to articles I have written or started
writing and all the JIRA issues.
The code for this is all ready, it just needs to be committed into the
subversion repository.
Note that just because the code would be part of the source code does
not mean it will be used. Specifically, the code has been set up at the
moment so the existing importer will still be used unless you explicitly
configure mod_python to use the new importer. If you want to try the new
module importer, you will be able to enable it for all Python
interpreter instances created, or selected ones. Only after sufficient
testing and tweaking as necessary, and after it has been deemed an
acceptable solution would it be properly integrated into mod_python as
the default. If people feel it isn't acceptable, it would be stripped
out of code and someone else can have a go with coming up with a
better alternative.
Graham