Re: 3.2.x branch
I've created the a 3.2.x branch. Just so we are all clear, the branches/3.2.x branch gets bug fixes *only*. This will be the source repository for future 3.2 bug fix releases. New features and major code modifications continue to go into trunk. I think any other new branches we create such as a 3.3 experimental module import branch should start with an alpha character so the stable 3.x.x branches don't get lost in the noise. eg. experimental-3.3 but not: 3.3-experimental Jim Gregory (Grisha) Trubetskoy wrote: On Thu, 9 Feb 2006, Jim Gallacher wrote: Looks good. As soon as you make the official announcement I'll create branches/3.2.x in svn and we can start on 3.3. I don't think we need to wait for the announcement - 3.2.7 is already out if you look on the download page, the announcement is more about marketing if you will. Grisha
Re: 3.2 beta release today?
On Tue, 16 Aug 2005, Jim Gallacher wrote: What is the correct name for the tarball? mod_python-3.2.0-b.tgz, mod_python-3.2.0-BETA.tgz or something else? I like mod_python-3.2.0b and the tarball would be mod_python-3.2.0b.tgz Grisha
Re: 3.2 beta release today?
Gregory (Grisha) Trubetskoy wrote: On Mon, 15 Aug 2005, Graham Dumpleton wrote: Does this imply no more fixes for outstanding problems even though the necessary patches have been posted up on JIRA. Eg,. If we stick to the schedule, then yes. http://issues.apache.org/jira/browse/MODPYTHON-12 The patch for this one would have eliminated the last workaround that I keep having to propagate in my code, even though the minimum requirement for my code was going to be to have 3.2. Guess I'll have to go back and put the workaround in again until 3.2.X. :-( But you have an opportunity to vote -1 on the new tarball because of this issue (the rules are that anyone on this list can vote). It does not look like a major patch. The diff is only a few lines. I can commit it as the last act before shoving the beta out the door today. Jim
Re: 3.2 beta release today?
I think the best thing to do is just to go ahead and tag and a create a tarball. Whether everyone was ready will become apparent during the testing/voting. Grisha On Mon, 15 Aug 2005, Jim Gallacher wrote: Are we on track to release a 3.2.0beta tarball today? Regards, Jim
Re: 3.2 Compile problems with gcc 4.0
Gregory (Grisha) Trubetskoy wrote: On Wed, 10 Aug 2005, Jim Gallacher wrote: Compilation fails with the following: requestobject.c: In function 'request_tp_dealloc': requestobject.c:1482: warning: implicit declaration of function 'request_tp_clear' This looks like a bug - I guess GCC 3 defaulted to static for implicitely declared functions, or perhaps didn't mind a non-static declaration followed by a static declaration. gcc 3.3 just generates a warning: requestobject.c: In function `request_tp_dealloc': requestobject.c:1479: warning: implicit declaration of function `request_tp_clear' requestobject.c: At top level: requestobject.c:1511: warning: `request_tp_clear' was declared implicitly `extern' and later `static' requestobject.c:1479: warning: previous declaration of `request_tp_clear' As a sidenote - (wearing my dictator hat) - we really should be following the Apache coding style - having no spaces after if and several statements per line makes it difficult to read. Also, repetitive code is probably a good case for using an extra function or a macro (macro's should be last resort though because they can be hard to read and debug - but in this particular case a macro may be just fine) OK, chief. :) I don't mind doing an audit for Apache coding style compliance, but in a post 3.2.0 time frame. Let's not start mucking with working code just before the release. It's easy enough to fix (and I will) by adding a function prototype for request_tp_clear before it is called in request_tp_dealloc(). eg. static int request_tp_clear(requestobject *self); I think it can be fixed by simply moving tp_dealloc after tp_clear. This is true, but I wasn't sure if it that was the preferred way. I've noticed that in general functions are implicitly declared in mod_python. Is there a technical reason for this, or is it just one of those things? Not really - implicit declaration is when something is referenced before being declared which in most cases results in compilation errors. What you probably mean to say is that they do not have forward declarations, but you generally don't need them if code is ordered correctly - there is no reason to have a forward declaration for every function. OK. I'll fix the bug by moving request_tp_clear ahead of request_tp_dealloc. Jim
Re: 3.2
MODPYTHON-34 has been fixed in the current version of the publisher, with the new importing system. As I've written before, I can roll back the part regarding the import system if you really want that, all the while maintaining the fix for MODPYTHON-34. Regards, Nicolas2005/7/29, Graham Dumpleton [EMAIL PROTECTED]: Sorry, getting a bit overwhelmed with all these rapid changes in stateof things as bit busy today. Will probably will only know what is goingon when I look at latest code in repository. Then I'll probably pipe in with some more pertinent comments about 3.2.One report I would like to get some confirmation about is:http://issues.apache.org/jira/browse/MODPYTHON-34 This was about a potential security hole. Nicolas has indicated thatchanges he had been working on which involved a different moduleloader addressed it, but if various things are getting pushed to 3.3, is then this addressed or not in what would make it to 3.2?Since it was security related, just wanted to highlight it even ifexposure risk is low.BTW, did anyone see an issue with my proposal for making the req.path_info attribute writable. Ie.,http://issues.apache.org/jira/browse/MODPYTHON-67I have been working on some code which would depend on such a change and the code is of a nature that I think would be a nicecandidate for rolling back into the mod_python core. If path_infowas writable in 3.2, would allow people to experiment with the codeI am working on, or even turn it into a common project, without needing to patch the mod_python source code.I know Jim gave a +1 for path_info to be writable.GrahamJim Gallacher wrote .. Jim Gallacher wrote: Gregory (Grisha) Trubetskoy wrote: On Thu, 28 Jul 2005, Nicolas Lehuen wrote: Note that there are 29 unscheduled issues : http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolutionIds=-1pid=10640fixfor=-1 Maybe some of them should be included in the 3.2 release ? My inclanation is to just release whatever we have, and mark it as a beta release. The last true release was 3.1.3 in Feb 2004, which makes it 18 months (if my math is correct) Grisha I've either commited fixes or have fixes ready for 6 or 8 of those issues. Also there some that don't apply to 3.2 (eg website or mailing list issues). Must run right now but will make a list this evening of issues which can be closed. Jim Here is my list. I think you can close all of these JIRA issues except MODPYTHON-52. http://issues.apache.org/jira/browse/MODPYTHON-45 Implement a file-based session manager Resolved but waiting for documentation. Working on it now - will commit in the next 12 hours. http://issues.apache.org/jira/browse/MODPYTHON-58 _apache._global_lock results in segfault when index number of mutexes Fix has been commited http://issues.apache.org/jira/browse/MODPYTHON-62 local_ip and local_host in connection object returns remote_ip and remote_host instead This issue only applies to 3.1.4. It's already been fixed in 3.2. http://issues.apache.org/jira/browse/MODPYTHON-65 3.2 working version will not install on Mac OS X ( 10.3.7) Fix has been commited. http://issues.apache.org/jira/browse/MODPYTHON-66 install_dso target also tries to install Python code files Fix has been commited. http://issues.apache.org/jira/browse/MODPYTHON-59 Add get_session() method to request object Let's defer this to 3.3. I've changed current implementation to raise a NotImplemented error. Related to get_session, I've made a small change to Session.Session(). It now checks PythonOption session for the default session type before using the hard coded default. For reasons that escape me I put this in a separate function, create_session(), but it really belongs in Session(). This is useful outside of get_session, so I've kept the change for 3.2. Regards, Jim
Re: 3.2 (import and publisher issues)
Nicolas Lehuen wrote: MODPYTHON-34 has been fixed in the current version of the publisher, with the new importing system. As I've written before, I can roll back the part regarding the import system if you really want that, all the while maintaining the fix for MODPYTHON-34. I haven't had much to say on this topic (because I don't have a solid grasp of all the implications), but it seems like it's a real stumbling block for the release. I'd say if the current changes won't break any current code, or cause users unexpected behaviour, leave them in. Otherwise roll them back. It's better for the user to have to deal with old, documentented issues rather than discover brand new ones in their code, only to find we've changed the behaviour again in 3.3. Whichever route we take, we will obviously work on this further in 3.3 but for now let's get 3.2.0b out the door. Regards, Jim
Re: 3.2 (import and publisher issues)
I'd like to stress the fact that a lot of issues currently in JIRA are related to the publisher. We have worked on it to solve some of these issues. I have made sure that both the old version and the new version pass a series of unit tests. I can't be sure that those unit tests reflect the whole range of usage patterns people could have of the publisher, but anyway, it's better than nothing. So, I think we should move forward on the 3.2 release. The new publisher code is meant to make it work better, not worse, while retaining the compatibility with the current code. It's not a new publisher, it's a set of bug fixes. I mean, what is the purpose of releasing a new version of mod_python if we don't fix the dozen of bugs that are related to the publisher ? Regards, Nicolas2005/8/10, Jim Gallacher [EMAIL PROTECTED]: Nicolas Lehuen wrote: MODPYTHON-34 has been fixed in the current version of the publisher, with the new importing system. As I've written before, I can roll back the part regarding the import system if you really want that, all the while maintaining the fix for MODPYTHON-34.I haven't had much to say on this topic (because I don't have a solidgrasp of all the implications), but it seems like it's a real stumblingblock for the release. I'd say if the current changes won't break any current code, or causeusers unexpected behaviour, leave them in. Otherwise roll them back.It's better for the user to have to deal with old, documentented issues rather than discover brand new ones in their code, only to find we'vechanged the behaviour again in 3.3.Whichever route we take, we will obviously work on this further in 3.3but for now let's get 3.2.0b out the door.Regards,Jim
Re: 3.2 (import and publisher issues)
Nicolas Lehuen wrote: I'd like to stress the fact that a lot of issues currently in JIRA are related to the publisher. We have worked on it to solve some of these issues. I have made sure that both the old version and the new version pass a series of unit tests. I can't be sure that those unit tests reflect the whole range of usage patterns people could have of the publisher, but anyway, it's better than nothing. So, I think we should move forward on the 3.2 release. +1 The new publisher code is meant to make it work better, not worse, while retaining the compatibility with the current code. It's not a new publisher, it's a set of bug fixes. I mean, what is the purpose of releasing a new version of mod_python if we don't fix the dozen of bugs that are related to the publisher ? Regards, Nicolas 2005/8/10, Jim Gallacher [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Nicolas Lehuen wrote: MODPYTHON-34 has been fixed in the current version of the publisher, with the new importing system. As I've written before, I can roll back the part regarding the import system if you really want that, all the while maintaining the fix for MODPYTHON-34. I haven't had much to say on this topic (because I don't have a solid grasp of all the implications), but it seems like it's a real stumbling block for the release. I'd say if the current changes won't break any current code, or cause users unexpected behaviour, leave them in. Otherwise roll them back. It's better for the user to have to deal with old, documentented issues rather than discover brand new ones in their code, only to find we've changed the behaviour again in 3.3. Whichever route we take, we will obviously work on this further in 3.3 but for now let's get 3.2.0b out the door. Regards, Jim
Re: 3.2
Just thought I'd ask if we're making any progress towards a 3.2 tarball to test. No pressure, just curious :-) Grisha
Re: 3.2
Gregory (Grisha) Trubetskoy wrote: On Thu, 28 Jul 2005, Nicolas Lehuen wrote: Note that there are 29 unscheduled issues : http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolutionIds=-1pid=10640fixfor=-1 Maybe some of them should be included in the 3.2 release ? My inclanation is to just release whatever we have, and mark it as a beta release. The last true release was 3.1.3 in Feb 2004, which makes it 18 months (if my math is correct) Grisha I've either commited fixes or have fixes ready for 6 or 8 of those issues. Also there some that don't apply to 3.2 (eg website or mailing list issues). Must run right now but will make a list this evening of issues which can be closed. Jim
Re: 3.2
Gregory (Grisha) Trubetskoy wrote: On Thu, 28 Jul 2005, Jim Gallacher wrote: I've either commited fixes or have fixes ready for 6 or 8 of those issues. Also there some that don't apply to 3.2 (eg website or mailing list issues). Must run right now but will make a list this evening of issues which can be closed. Do you think you'll be able to create a tgz file? It would really be fantastic if someone other than me could do it. Grisha Yes I can do that. I've already done a couple of dry runs with good success. Jim
Re: 3.2
Sorry, getting a bit overwhelmed with all these rapid changes in state of things as bit busy today. Will probably will only know what is going on when I look at latest code in repository. Then I'll probably pipe in with some more pertinent comments about 3.2. One report I would like to get some confirmation about is: http://issues.apache.org/jira/browse/MODPYTHON-34 This was about a potential security hole. Nicolas has indicated that changes he had been working on which involved a different module loader addressed it, but if various things are getting pushed to 3.3, is then this addressed or not in what would make it to 3.2? Since it was security related, just wanted to highlight it even if exposure risk is low. BTW, did anyone see an issue with my proposal for making the req.path_info attribute writable. Ie., http://issues.apache.org/jira/browse/MODPYTHON-67 I have been working on some code which would depend on such a change and the code is of a nature that I think would be a nice candidate for rolling back into the mod_python core. If path_info was writable in 3.2, would allow people to experiment with the code I am working on, or even turn it into a common project, without needing to patch the mod_python source code. I know Jim gave a +1 for path_info to be writable. Graham Jim Gallacher wrote .. Jim Gallacher wrote: Gregory (Grisha) Trubetskoy wrote: On Thu, 28 Jul 2005, Nicolas Lehuen wrote: Note that there are 29 unscheduled issues : http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolutionIds=-1pid=10640fixfor=-1 Maybe some of them should be included in the 3.2 release ? My inclanation is to just release whatever we have, and mark it as a beta release. The last true release was 3.1.3 in Feb 2004, which makes it 18 months (if my math is correct) Grisha I've either commited fixes or have fixes ready for 6 or 8 of those issues. Also there some that don't apply to 3.2 (eg website or mailing list issues). Must run right now but will make a list this evening of issues which can be closed. Jim Here is my list. I think you can close all of these JIRA issues except MODPYTHON-52. http://issues.apache.org/jira/browse/MODPYTHON-45 Implement a file-based session manager Resolved but waiting for documentation. Working on it now - will commit in the next 12 hours. http://issues.apache.org/jira/browse/MODPYTHON-58 _apache._global_lock results in segfault when index number of mutexes Fix has been commited http://issues.apache.org/jira/browse/MODPYTHON-62 local_ip and local_host in connection object returns remote_ip and remote_host instead This issue only applies to 3.1.4. It's already been fixed in 3.2. http://issues.apache.org/jira/browse/MODPYTHON-65 3.2 working version will not install on Mac OS X (10.3.7) Fix has been commited. http://issues.apache.org/jira/browse/MODPYTHON-66 install_dso target also tries to install Python code files Fix has been commited. http://issues.apache.org/jira/browse/MODPYTHON-59 Add get_session() method to request object Let's defer this to 3.3. I've changed current implementation to raise a NotImplemented error. Related to get_session, I've made a small change to Session.Session(). It now checks PythonOption session for the default session type before using the hard coded default. For reasons that escape me I put this in a separate function, create_session(), but it really belongs in Session(). This is useful outside of get_session, so I've kept the change for 3.2. Regards, Jim
