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. MODPYTHON-77 The Simplified GIL Aquisition patches. MODPYTHON-78 Apache 2.2 patches. MODPYTHON-94 Support for optional mod_ssl functions on request object. MODPYTHON-113 Make PythonImport use apache.import_module() via CallBack method. MODPYTHON-119 DBM Session test patches. MODPYTHON-122 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? Graham
