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).
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.
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
