Jim Gallacher wrote .. > Graham Dumpleton wrote: > > Is my list of suggested JIRA items then seen as being reasonable for > > such a projected release? > > This seems reasonable, since we have either already committed the fixes > or have patches available (I think).
I don't have changes ready for MODPYTHON-113, having PythonImport use apache.import_module(). I am quite happy to drop that from the list as would need to be sure that one worked okay. Might also be a good idea to defer that anyway to also address MODPYTHON-117 and MODPYTHON-118 at the same time as changing code in same area. All the rest in my list we have code ready for. > > Do we want to create a new JIRA issue for the mutex directory issue and > > also include a fix for that, but limit it to just an option to configure > > to override the directory? > > I can live with that. I don't like the idea of adding alot of new > functionality into a bugfix release, but a configure option is a pretty > minor change. The configure option is probably still good to have even if later we decide to also allow it to be overridden in Apache configuration. Possibly doesn't help to solve any conflict issues with test suite though. > Jim > > > > Graham > > > > Nicolas Lehuen wrote .. > > > >>Based on today's traffic on the mailing lists, I think that we should > >>go for a short-term 3.2.8 release of mod_python, with certified Apache > >>2.2 support on multiple platforms. The code is only there but I > >>suppose we'll need a lot of testing, so maybe we could expect to > >>release this in a month or two (given that the Win32 source code is > >>not even available right now). > >> > >>Regards, > >>Nicolas > >> > >>2006/2/14, Nicolas Lehuen <[EMAIL PROTECTED]>: > >> > >>>2006/2/14, Graham Dumpleton <[EMAIL PROTECTED]>: > >>>[...] > >>> > >>>>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 > >>>> > >>> > >>>I was thinking about working on the new test framework in parallel of > >>>"real work", away from the trunk (in my /branches/nlehuen directory). > >>>I don't think it will be too hard to track down the changes in the > >>>trunk tests and bring them back in the new test framework, but I may > >>>be wrong. One the new tests are available, I'll merge them back in the > >>>trunk. > >>> > >>>So I guess it's not necessary to hold back the next release do to the > >>>tests, and it may be a good exercise to due a few 3.2.x releases in > a > >>>short period of time before doing the 3.3.x release. > >>> > >>>Regards, > >>>Nicolas > >>> > > > >
