Is my list of suggested JIRA items then seen as being reasonable for such a projected release?
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? 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 > >
