Re: svn commit: r1491612 - /httpd/httpd/branches/2.4.x/STATUS
On Wednesday 12 June 2013 21:18:05 Stefan Fritsch wrote: On Tuesday 11 June 2013, André Malo wrote: trunk patch: http://svn.apache.org/r1491155 2.4.x patch: trunk patch works nd: why would you do that in a stable branch? + sf: Because it is only annoying and serves no purpose anymore. If you + want, we can make it a minor MMN bump for adding a new API. +1: sf, covener -1: nd Long discussions in STATUS are kinda tedious ;-) Well, I think, such changes are what trunk is for. Why not simply leave everything below as-is? Even more if it removes only an annoyance? Or is there a real technical reason I'm just not seeing right now? [...] Or, is there a real technical reason to keep it broken in 2.4? Annoying rhetoric games aside - we went from only annoying to broken. What is it now? No other opinion on this? nd
Re: svn commit: r1491612 - /httpd/httpd/branches/2.4.x/STATUS
On 14.06.2013 16:41, André Malo wrote: On Wednesday 12 June 2013 21:18:05 Stefan Fritsch wrote: On Tuesday 11 June 2013, André Malo wrote: trunk patch: http://svn.apache.org/r1491155 2.4.x patch: trunk patch works nd: why would you do that in a stable branch? + sf: Because it is only annoying and serves no purpose anymore. If you + want, we can make it a minor MMN bump for adding a new API. +1: sf, covener -1: nd Long discussions in STATUS are kinda tedious ;-) Well, I think, such changes are what trunk is for. Why not simply leave everything below as-is? Even more if it removes only an annoyance? Or is there a real technical reason I'm just not seeing right now? [...] Or, is there a real technical reason to keep it broken in 2.4? Annoying rhetoric games aside - we went from only annoying to broken. What is it now? No other opinion on this? As far as I understand the matter, the block removed by the above commit would throw a compiler error if code uses strtoul() and includes httpd.h. The motivation was that at the time the block was introduced some supported platforms, e.g. SunOS 4, did not have strtoul(), so it was helpful to throw that error even when compiled on other platforms to ensure compatibility. The error will also be thrown for any 3rd-party code that uses strtoul() and includes httpd.h when being compiled - so practically all modules are prohibited to use strtoul(). The function is part of C89 which we assume as a minimum when compiling Apache 2.4. So I do not see any positive effects of the old block. I do recognize, that it breaks module compilation for modules using strtoul(). So the proposed change removes an obstacle for full CC89 support in modules. Furthermore I can not imagine any risk of breaking stuff that worked before removing the block. Based on that I am +1 to remove the block. Regards, Rainer
Re: svn commit: r1491612 - /httpd/httpd/branches/2.4.x/STATUS
On Fri, Jun 14, 2013 at 10:41 AM, André Malo n...@perlig.de wrote: On Wednesday 12 June 2013 21:18:05 Stefan Fritsch wrote: On Tuesday 11 June 2013, André Malo wrote: trunk patch: http://svn.apache.org/r1491155 2.4.x patch: trunk patch works nd: why would you do that in a stable branch? + sf: Because it is only annoying and serves no purpose anymore. If you + want, we can make it a minor MMN bump for adding a new API. +1: sf, covener -1: nd Long discussions in STATUS are kinda tedious ;-) Well, I think, such changes are what trunk is for. Why not simply leave everything below as-is? Even more if it removes only an annoyance? Or is there a real technical reason I'm just not seeing right now? [...] Or, is there a real technical reason to keep it broken in 2.4? Annoying rhetoric games aside - we went from only annoying to broken. What is it now? No other opinion on this? I think Stefan did it justice in the STATUS remark. I don't really understand the objection. Are you afraid a strtoul will sneak into one of our modules, or that a module developer needs this macro to protect them from it? -- Eric Covener cove...@gmail.com
Re: svn commit: r1491612 - /httpd/httpd/branches/2.4.x/STATUS
On Friday 14 June 2013 17:34:26 Rainer Jung wrote: On 14.06.2013 16:41, André Malo wrote: On Wednesday 12 June 2013 21:18:05 Stefan Fritsch wrote: On Tuesday 11 June 2013, André Malo wrote: trunk patch: http://svn.apache.org/r1491155 2.4.x patch: trunk patch works nd: why would you do that in a stable branch? + sf: Because it is only annoying and serves no purpose anymore. If you + want, we can make it a minor MMN bump for adding a new API. +1: sf, covener -1: nd Long discussions in STATUS are kinda tedious ;-) Well, I think, such changes are what trunk is for. Why not simply leave everything below as-is? Even more if it removes only an annoyance? Or is there a real technical reason I'm just not seeing right now? [...] Or, is there a real technical reason to keep it broken in 2.4? Annoying rhetoric games aside - we went from only annoying to broken. What is it now? No other opinion on this? As far as I understand the matter, the block removed by the above commit would throw a compiler error if code uses strtoul() and includes httpd.h. The motivation was that at the time the block was introduced some supported platforms, e.g. SunOS 4, did not have strtoul(), so it was helpful to throw that error even when compiled on other platforms to ensure compatibility. The error will also be thrown for any 3rd-party code that uses strtoul() and includes httpd.h when being compiled - so practically all modules are prohibited to use strtoul(). The function is part of C89 which we assume as a minimum when compiling Apache 2.4. So I do not see any positive effects of the old block. I do recognize, that it breaks module compilation for modules using strtoul(). So the proposed change removes an obstacle for full CC89 support in modules. Furthermore I can not imagine any risk of breaking stuff that worked before removing the block. Based on that I am +1 to remove the block. I agree, that the block should simply die. However, I question the value of doing cosmetical changes in our stable branches (which is the justification in STATUS). So the question in this specific case is: is it a cosmetical change or not? nd
Re: svn commit: r1491612 - /httpd/httpd/branches/2.4.x/STATUS
On Jun 14, 2013 11:36 AM, Eric Covener cove...@gmail.com wrote: On Fri, Jun 14, 2013 at 10:41 AM, André Malo n...@perlig.de wrote: On Wednesday 12 June 2013 21:18:05 Stefan Fritsch wrote: On Tuesday 11 June 2013, André Malo wrote: trunk patch: http://svn.apache.org/r1491155 2.4.x patch: trunk patch works nd: why would you do that in a stable branch? + sf: Because it is only annoying and serves no purpose anymore. If you + want, we can make it a minor MMN bump for adding a new API. +1: sf, covener -1: nd Long discussions in STATUS are kinda tedious ;-) Well, I think, such changes are what trunk is for. Why not simply leave everything below as-is? Even more if it removes only an annoyance? Or is there a real technical reason I'm just not seeing right now? [...] Or, is there a real technical reason to keep it broken in 2.4? Annoying rhetoric games aside - we went from only annoying to broken. What is it now? No other opinion on this? I think Stefan did it justice in the STATUS remark. I don't really understand the objection. Are you afraid a strtoul will sneak into one of our modules, or that a module developer needs this macro to protect them from it? -- Eric Covener cove...@gmail.com If I can interject randomly... Give it a minor bump so module authors can hide their workarounds for older httpd in a self-documenting way, and so there's a CYA if some very odd, existing module workaround breaks unexpectedly...
Re: svn commit: r1491612 - /httpd/httpd/branches/2.4.x/STATUS
On 14.06.2013 17:44, André Malo wrote: On Friday 14 June 2013 17:34:26 Rainer Jung wrote: On 14.06.2013 16:41, André Malo wrote: On Wednesday 12 June 2013 21:18:05 Stefan Fritsch wrote: On Tuesday 11 June 2013, André Malo wrote: trunk patch: http://svn.apache.org/r1491155 2.4.x patch: trunk patch works nd: why would you do that in a stable branch? + sf: Because it is only annoying and serves no purpose anymore. If you + want, we can make it a minor MMN bump for adding a new API. +1: sf, covener -1: nd Long discussions in STATUS are kinda tedious ;-) Well, I think, such changes are what trunk is for. Why not simply leave everything below as-is? Even more if it removes only an annoyance? Or is there a real technical reason I'm just not seeing right now? [...] Or, is there a real technical reason to keep it broken in 2.4? Annoying rhetoric games aside - we went from only annoying to broken. What is it now? No other opinion on this? As far as I understand the matter, the block removed by the above commit would throw a compiler error if code uses strtoul() and includes httpd.h. The motivation was that at the time the block was introduced some supported platforms, e.g. SunOS 4, did not have strtoul(), so it was helpful to throw that error even when compiled on other platforms to ensure compatibility. The error will also be thrown for any 3rd-party code that uses strtoul() and includes httpd.h when being compiled - so practically all modules are prohibited to use strtoul(). The function is part of C89 which we assume as a minimum when compiling Apache 2.4. So I do not see any positive effects of the old block. I do recognize, that it breaks module compilation for modules using strtoul(). So the proposed change removes an obstacle for full CC89 support in modules. Furthermore I can not imagine any risk of breaking stuff that worked before removing the block. Based on that I am +1 to remove the block. I agree, that the block should simply die. However, I question the value of doing cosmetical changes in our stable branches (which is the justification in STATUS). So the question in this specific case is: is it a cosmetical change or not? We do cosmetical changes in stable branches like e.g. reducing code drift between trunk and 2.4 or fixing typos in comments. We do it if we see only very little risk and anticipate at least some benefit now or for the future. In the case discussed here I'd say the risk is very small and the benefit of a more complete c89 support for module authors is real (but of course not big). I like the addition of the MMN bump suggested by Jeff. Regards, Rainer
AW: svn commit: r1491612 - /httpd/httpd/branches/2.4.x/STATUS
-Ursprüngliche Nachricht- Von: Rainer Jung [] Gesendet: Freitag, 14. Juni 2013 18:08 An: dev@httpd.apache.org Betreff: Re: svn commit: r1491612 - /httpd/httpd/branches/2.4.x/STATUS We do cosmetical changes in stable branches like e.g. reducing code drift between trunk and 2.4 or fixing typos in comments. We do it if we see only very little risk and anticipate at least some benefit now or for the future. In the case discussed here I'd say the risk is very small and the benefit of a more complete c89 support for module authors is real (but of course not big). I like the addition of the MMN bump suggested by Jeff. +1 Regards Rüdiger
Re: svn commit: r1491612 - /httpd/httpd/branches/2.4.x/STATUS
On Jun 14, 2013, at 11:44 AM, André Malo n...@perlig.de wrote: I agree, that the block should simply die. However, I question the value of doing cosmetical changes in our stable branches (which is the justification in STATUS). FWIW, I agree. I don't mind such clean-ups and cosmetic changes on trunk, but functional changes (and this is) require a backport proposal.
Re: svn commit: r1491612 - /httpd/httpd/branches/2.4.x/STATUS
On Jun 14, 2013, at 12:07 PM, Rainer Jung rainer.j...@kippdata.de wrote: We do cosmetical changes in stable branches like e.g. reducing code drift between trunk and 2.4 or fixing typos in comments. Of course. That's not the question (at least IMO). The question is that when a cosmetic change also results in a functional change (and we wouldn't be suggesting MMN bumps if it wasn't), that it becomes a change that should be proposed as a backport and not willy-nilly added. We have a process, and should discourage attempts to bypass it on a stable trunk. FWIW, I'd be +1 with the bump.
Re: svn commit: r1491612 - /httpd/httpd/branches/2.4.x/STATUS
Of course. That's not the question (at least IMO). The question is that when a cosmetic change also results in a functional change (and we wouldn't be suggesting MMN bumps if it wasn't), that it becomes a change that should be proposed as a backport and not willy-nilly added. We have a process, and should discourage attempts to bypass it on a stable trunk. This change followed the process. It currently sits in 2.4.x/STATUS.
Re: svn commit: r1491612 - /httpd/httpd/branches/2.4.x/STATUS
On Jun 14, 2013, at 1:20 PM, Eric Covener cove...@gmail.com wrote: Of course. That's not the question (at least IMO). The question is that when a cosmetic change also results in a functional change (and we wouldn't be suggesting MMN bumps if it wasn't), that it becomes a change that should be proposed as a backport and not willy-nilly added. We have a process, and should discourage attempts to bypass it on a stable trunk. This change followed the process. It currently sits in 2.4.x/STATUS. I know... I voted on it :) I was speaking in generalities... sorry for the confusion.
Re: svn commit: r1491612 - /httpd/httpd/branches/2.4.x/STATUS
On Tuesday 11 June 2013, André Malo wrote: trunk patch: http://svn.apache.org/r1491155 2.4.x patch: trunk patch works nd: why would you do that in a stable branch? + sf: Because it is only annoying and serves no purpose anymore. If you + want, we can make it a minor MMN bump for adding a new API. +1: sf, covener -1: nd Long discussions in STATUS are kinda tedious ;-) Well, I think, such changes are what trunk is for. Why not simply leave everything below as-is? Even more if it removes only an annoyance? Or is there a real technical reason I'm just not seeing right now? It is a useful function. Disallowing it breaks ISO-C compliant code for no good reason. There has been a complaint by a module author. Allowing it does not use any memory because the function is already in libc. Working around the missing function requires additional code, which uses memory and may contain bugs. What more reasons do you need? Or, is there a real technical reason to keep it broken in 2.4?
Re: svn commit: r1491612 - /httpd/httpd/branches/2.4.x/STATUS
* s...@apache.org wrote: Author: sf Date: Mon Jun 10 21:41:07 2013 New Revision: 1491612 URL: http://svn.apache.org/r1491612 Log: comment Modified: httpd/httpd/branches/2.4.x/STATUS Modified: httpd/httpd/branches/2.4.x/STATUS URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=149161 2r1=1491611r2=1491612view=diff = = --- httpd/httpd/branches/2.4.x/STATUS (original) +++ httpd/httpd/branches/2.4.x/STATUS Mon Jun 10 21:41:07 2013 @@ -198,6 +198,8 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: trunk patch: http://svn.apache.org/r1491155 2.4.x patch: trunk patch works nd: why would you do that in a stable branch? + sf: Because it is only annoying and serves no purpose anymore. If you + want, we can make it a minor MMN bump for adding a new API. +1: sf, covener -1: nd Long discussions in STATUS are kinda tedious ;-) Well, I think, such changes are what trunk is for. Why not simply leave everything below as-is? Even more if it removes only an annoyance? Or is there a real technical reason I'm just not seeing right now? nd -- Solides und umfangreiches Buch -- aus einer Rezension http://pub.perlig.de/books.html#apache2
