Jim Gallacher wrote ..
> Jorey Bump wrote:
> > Jim Gallacher wrote:
> > 
> >> This is how I would set priorities:
> > 
> > 
> >> Try and assign most of the issues to someone. This is a bit of PR 
> >> spin, but I think it looks bad when there are a large number of open
> >> issues with no assignee. To the public it may look like the project
> is 
> >> not being actively maintained.
> > 
> > 
> > I think the same can be said for the lack of Apache 2.2 support. 
> > Personally, I would put this (as well as backporting 2.2 support to 
> > mod_python 3.2) as the number one priority, for both PR and pragmatic
> > reasons.
> > 
> > The need for compatibility with Apache 2.0 & 2.2 is going to be an issue
> > for quite a while, and should be addressed before mod_python undergoes
> > some of the significant changes that have been discussed.
> Apache 2.2 support has already been checked into svn trunk. It's just a
> question of doing the backport to the 3.2.x branch once we've seen some
> testing. I think we should plan on doing regular 3.2.x bugfix releases
> so that the 3.3 dev branch can mature without the pressure making a 
> release just to fix bugs.

If we want to go down the path of having interim 3.2 bug rollup releases
while 3.3 is being developed, might I suggest that we target the following
for such a release in the near future.


  The Simplified GIL Aquisition patches.


  Apache 2.2 patches.


  Support for optional mod_ssl functions on request object.


  Make PythonImport use apache.import_module() via CallBack method.


  DBM Session test patches.


  Bash 3.1.X configure patches.

I know that MODPYTHON-94 isn't a bug fix, but a few people have been after
this one. Also MODPYTHON-113 may not seem important, but will mean
that any test package I make available for new importer will work properly
in all cases where module imports occur.

Anyway, after trolling through JIRA, these seemed to be the important ones
to me, but other might have other suggestions.

Now, the question is how we manage this. Do we concentrate on these only
in the trunk and get them out of the way first as a 3.2.X release, holding back
any changes to test framework? Or do we merge such changes from trunk on
a case by case basis in 3.2.X branch?


Reply via email to