Re: Getting Started on mod_python 3.3.
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 > >>> > > > >
Re: Getting Started on mod_python 3.3.
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
Re: Getting Started on mod_python 3.3.
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 > >
Re: Getting Started on mod_python 3.3.
Grisha wrote .. > > On Tue, 14 Feb 2006, Nicolas Lehuen wrote: > > > 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. > > If this is the one where you get "Restriction Execution" errors upon > launching a thread, then I'm kinda keen on seeing this fixed sooner than > later. Just my $0.02. :-) Yes it is. Note that there is one caveat on this fix because of how simple GIL works when there are multiple interpreters. Namely, if using third party code which uses simple GIL API, then "PythonInterpreter" must be explicitly set to "main_interpreter" for context the code is used in. This interpreter is now gauranteed to be the first interpreter which was created, thus satisfying simple GIL requirements. No real drama, we just need to document this fact. Graham
Re: Getting Started on mod_python 3.3.
On Tue, 14 Feb 2006, Nicolas Lehuen wrote: 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. If this is the one where you get "Restriction Execution" errors upon launching a thread, then I'm kinda keen on seeing this fixed sooner than later. Just my $0.02. :-) Grisha
Re: Getting Started on mod_python 3.3.
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). I'm not sure we need *alot* of testing on *nix. The APR_STATUS_IS_SUCCESS macro is not an issue there, since it is defined as (rc == APR_SUCCESS), which is the change we've made anyway. That macro does have a different definition on Win32, so that's where the testing needs to happen. But if there is no Apache 2.2 for Win32, where does that leave us wrt to a release? After Graham's digging and the comments from Justin I'm much less concerned about a potential problem on Win32. I don't think we should pile a large number of changes in any given 3.2.x bugfix release. If each release has not deviated too much from the previous version, then we'll need to do less testing and can release more frequently. I'd hate to see us wait 2 or 3 months for 3.2.8 and find we have so many bug fixes, and "little" feature additions that we then need to go through another 3.2.8 beta cycle. Release early and release often. Jim 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
Re: Getting Started on mod_python 3.3.
2006/2/14, Nicolas Lehuen <[EMAIL PROTECTED]>: > 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 Doh ! I've found the source code for Win32. I'll try to build it ASAP and give mod_python a try. Regards, Nicolas
Re: Getting Started on mod_python 3.3.
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 >
Re: Getting Started on mod_python 3.3.
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
Re: Getting Started on mod_python 3.3.
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
Re: Getting Started on mod_python 3.3.
Graham Dumpleton wrote: As Jim pointed out a while back, we need to get going on mod_python 3.3 before I fill up JIRA with another page of bug reports or suggestions. I think you already *have* filled another page since I made that comment. ;) That said, how do we want to proceed on this? Do we want to draw up an initial list of things to do with priorities, discuss them to make sure all are okay with the fix or what is proposed, possibly assign them to individuals, and then get started? Or even before that, do we want to state general aims about what we want to address in mod_python 3.3? Do we want to focus only on addressing bugs again, or look at some new features as well? This is how I would set priorities: Mark resolved bugs in JIRA as closed, just to clean things up. 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. Fix the easy bugs first so we can backport to 3.2, and be ready for a bugfix release. This does not include the various importer issues. I'd say that there are not many things in this category, but we should review JIRA to be sure. Refactor the unit tests. If we are going to do this, we should do it early in the development cycle so we have lots of time to test the test suite. Review JIRA and collect related issues. Improve documentation. New features. Grand Unified Import Theory. The order does not necessarily suggest the importance of the various issues, and of course we can work in parallel on the last 3 items. By then I might have got my SVN access sorted out. Have account, but haven't as yet tried a check out using it. BTW, I still don't have priviledges in JIRA to administer entries, ie., assign etc. Do I need/want that? How do I get that set up? It's handy to be able to assign, close and resolve issues, so I would say yes. I bevlieve Grisha can change your priviledges. Jim
Getting Started on mod_python 3.3.
As Jim pointed out a while back, we need to get going on mod_python 3.3 before I fill up JIRA with another page of bug reports or suggestions. That said, how do we want to proceed on this? Do we want to draw up an initial list of things to do with priorities, discuss them to make sure all are okay with the fix or what is proposed, possibly assign them to individuals, and then get started? Or even before that, do we want to state general aims about what we want to address in mod_python 3.3? Do we want to focus only on addressing bugs again, or look at some new features as well? By then I might have got my SVN access sorted out. Have account, but haven't as yet tried a check out using it. BTW, I still don't have priviledges in JIRA to administer entries, ie., assign etc. Do I need/want that? How do I get that set up? Graham
