Re: svn commit: r1349944 - /subversion/trunk/gen-make.py
On Thu, Jun 14, 2012 at 1:23 AM, Bert Huijben b...@qqmail.nl wrote: -Original Message- From: Hyrum K Wright [mailto:hyrum.wri...@wandisco.com] Sent: Thursday, June 14, 2012 12:33 AM To: Bert Huijben Cc: Michael Pilato; Subversion Development Subject: Re: svn commit: r1349944 - /subversion/trunk/gen-make.py On Wed, Jun 13, 2012 at 9:45 PM, Bert Huijben b...@qqmail.nl wrote: -Original Message- From: C. Michael Pilato [mailto:cmpil...@collab.net] Sent: Wednesday, June 13, 2012 9:34 PM To: dev@subversion.apache.org Cc: Hyrum K Wright; comm...@subversion.apache.org Subject: Re: svn commit: r1349944 - /subversion/trunk/gen-make.py On 06/13/2012 07:36 PM, Hyrum K Wright wrote: On Wed, Jun 13, 2012 at 6:10 PM, rhuij...@apache.org wrote: Author: rhuijben Date: Wed Jun 13 16:10:25 2012 New Revision: 1349944 URL: http://svn.apache.org/viewvc?rev=1349944view=rev Log: * gen-make.py Make the --with-neon= and --without-neon arguments on gen- make.py optional, just like how ./configure handles those. Windows doesn't use ./configure and this breaks tools that are friendly enough to provide hints. I don't like this change. ./configure *doesn't* work this way: it errors when attempting to provide the now-defunct neon options. Perhaps Bert meant only that, in general, configure allows you to specify options that it doesn't itself understand (while printing a warning about this fact). I think most distributions at least share some build code between versions. The buildbots only have a single set of dependencies for all the branches we are building. Only once we released 1.9.0 neon will be gone and before that we still have to support it (and even after that we still have to support all the Subversion 1.0-1.7 clients that still use neon) So, what you're saying is that we have single slaves, with single sets of scripts building multiple branches. And because of this, we can't change the dependencies or script arguments on trunk, for fear of breaking other branches. That sounds a bit like the tail wagging the dog. What would happen if we added a flag on trunk that one of the slaves needed to build, but didn't exist (and hence error'd) on other branches? Would we need to backport that flag as a no-op, simply to make the build slaves happen? That's exactly what this commit does, only in the forward direction. Things get very easy if you just break the few remaining buildbots without caring about the consequences, but it doesn’t make Subversion a better product. Making decisions simply to please the bots doesn't make Subversion a better product, either. They exist to help facilitate development. If there is a problem with the bots, then FIX THE BOTS, rather than introducing hacks in an attempt to please them. In this specific case that might mean a slightly more complex setup, which build each branch with a separate set of dependencies / scripts / inputs, since that's what end users will be doing anyway. Well, maybe you could help writing these scripts instead of breaking them because they have to broken anyway in the future. I choose not to maintain the bots you choose to host. The slave I host is currently offline, if/when it comes back on, I will address these issues which impact them. I have helped fix the centos buildslave, which I have knowledge of and access to. Breaking them 2 minutes after telling you that breaking them will cause huge problems that take much time to solve isn't helping things. You pointed out a deficiency in my prior patches, which I attempted to fix. Why do you prefer 2 of the 3 buildbots to be broken for at least the rest of the hackathon? I don't. Please don't put words in my mouth. Fixing the scripts for the bots, for SharpSvn, for the Slik distribution, for CollabNet's build and several test scenarios takes time certainly more time than the 5 minutes you provided. Those aren't my responsibility. While I think we should be respectful of downstream users, people who choose to build directly against trunk on a regular basis have to know they are working against a moving target, and such breakage is possible, and even quasi-expected. And probably more than a few weeks if I'm not delaying other work, which I would have to do if as all my build environments are broken by this change. Note that I have not asked that you revert this change. I just said that I don't like it, because we should think strongly about the precedent this sets. The flags to gen-make.py and other build scripts are *not* part of our backward compat guarantees, and we shouldn't feel required to support them indefinitely. (I noticed your response doesn't address the questions I asked along these lines.) -Hyrum -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com/
Re: svn commit: r1349944 - /subversion/trunk/gen-make.py
I agree: we should not make changes to Subversion simply to support some buildbots. That is the wrong direction. The buildbots must compensate for changes in *our* codebase. If we add new dependencies, then they must adjust. If we remove dependencies, then they must adjust. On Thu, Jun 14, 2012 at 3:26 AM, Hyrum K Wright hyrum.wri...@wandisco.com wrote: On Thu, Jun 14, 2012 at 1:23 AM, Bert Huijben b...@qqmail.nl wrote: -Original Message- From: Hyrum K Wright [mailto:hyrum.wri...@wandisco.com] Sent: Thursday, June 14, 2012 12:33 AM To: Bert Huijben Cc: Michael Pilato; Subversion Development Subject: Re: svn commit: r1349944 - /subversion/trunk/gen-make.py On Wed, Jun 13, 2012 at 9:45 PM, Bert Huijben b...@qqmail.nl wrote: -Original Message- From: C. Michael Pilato [mailto:cmpil...@collab.net] Sent: Wednesday, June 13, 2012 9:34 PM To: dev@subversion.apache.org Cc: Hyrum K Wright; comm...@subversion.apache.org Subject: Re: svn commit: r1349944 - /subversion/trunk/gen-make.py On 06/13/2012 07:36 PM, Hyrum K Wright wrote: On Wed, Jun 13, 2012 at 6:10 PM, rhuij...@apache.org wrote: Author: rhuijben Date: Wed Jun 13 16:10:25 2012 New Revision: 1349944 URL: http://svn.apache.org/viewvc?rev=1349944view=rev Log: * gen-make.py Make the --with-neon= and --without-neon arguments on gen- make.py optional, just like how ./configure handles those. Windows doesn't use ./configure and this breaks tools that are friendly enough to provide hints. I don't like this change. ./configure *doesn't* work this way: it errors when attempting to provide the now-defunct neon options. Perhaps Bert meant only that, in general, configure allows you to specify options that it doesn't itself understand (while printing a warning about this fact). I think most distributions at least share some build code between versions. The buildbots only have a single set of dependencies for all the branches we are building. Only once we released 1.9.0 neon will be gone and before that we still have to support it (and even after that we still have to support all the Subversion 1.0-1.7 clients that still use neon) So, what you're saying is that we have single slaves, with single sets of scripts building multiple branches. And because of this, we can't change the dependencies or script arguments on trunk, for fear of breaking other branches. That sounds a bit like the tail wagging the dog. What would happen if we added a flag on trunk that one of the slaves needed to build, but didn't exist (and hence error'd) on other branches? Would we need to backport that flag as a no-op, simply to make the build slaves happen? That's exactly what this commit does, only in the forward direction. Things get very easy if you just break the few remaining buildbots without caring about the consequences, but it doesn’t make Subversion a better product. Making decisions simply to please the bots doesn't make Subversion a better product, either. They exist to help facilitate development. If there is a problem with the bots, then FIX THE BOTS, rather than introducing hacks in an attempt to please them. In this specific case that might mean a slightly more complex setup, which build each branch with a separate set of dependencies / scripts / inputs, since that's what end users will be doing anyway. Well, maybe you could help writing these scripts instead of breaking them because they have to broken anyway in the future. I choose not to maintain the bots you choose to host. The slave I host is currently offline, if/when it comes back on, I will address these issues which impact them. I have helped fix the centos buildslave, which I have knowledge of and access to. Breaking them 2 minutes after telling you that breaking them will cause huge problems that take much time to solve isn't helping things. You pointed out a deficiency in my prior patches, which I attempted to fix. Why do you prefer 2 of the 3 buildbots to be broken for at least the rest of the hackathon? I don't. Please don't put words in my mouth. Fixing the scripts for the bots, for SharpSvn, for the Slik distribution, for CollabNet's build and several test scenarios takes time certainly more time than the 5 minutes you provided. Those aren't my responsibility. While I think we should be respectful of downstream users, people who choose to build directly against trunk on a regular basis have to know they are working against a moving target, and such breakage is possible, and even quasi-expected. And probably more than a few weeks if I'm not delaying other work, which I would have to do if as all my build environments are broken by this change. Note that I have not asked that you revert this change. I just said that I don't like it, because we should think strongly about the precedent this sets. The flags to gen
RE: svn commit: r1349944 - /subversion/trunk/gen-make.py
-Original Message- From: Greg Stein [mailto:gst...@gmail.com] Sent: Thursday, June 14, 2012 10:44 AM To: Bert Huijben; Hyrum K Wright Cc: dev@subversion.apache.org Subject: Re: svn commit: r1349944 - /subversion/trunk/gen-make.py I agree: we should not make changes to Subversion simply to support some buildbots. That is the wrong direction. The buildbots must compensate for changes in *our* codebase. If we add new dependencies, then they must adjust. If we remove dependencies, then they must adjust. Ok, maybe the response might have been: We should wait a few days before breaking every Windows Subversion development environment to allow them to be fixed first. I spent most of the night to get things fixed. (Last commit after 3 AM, and the final fixes on the buildbot after I woke up) But I don't understand why somebody just commits a change that he knows break things for at least two other developers on the same table. (I had to fix Markus development environment too, as he couldn't test the work he was working on) Most unix developers just assume that looking in a system library to find things like apr, serf, neon etc. works on all systems. Windows is by default not a development environment, so there is no standard place to look for these things and to work stable we pass explicit arguments. Just removing the arguments without notice is breaking things directly without a way to recover using the normal routing.. Just like breaking you development svn for commits or reverts breaks your entire workflow. I explicitly told Hyrum to wait with this specific change, as this impacts more people than all the other removal he did. And instead of providing some time or discussing this change on list he just broke things for me and others depending on these flags. I don't care that this flag will be gone with 1.8, we can catch up well before that. And I think for most my cases I did, but maybe others need some time too. This is not just about the buildbots, this is about workflows that are just broken beyond repair without notice. I would have liked to have some time to fix things before everything that depends on it breaks down. I noted the problem as I assumed that he didn't know about things relying on them and he explicitly used that information to apply this as a change that 'he forgot about'. This is just working against other developers. And this entire thread delays things more. Feel free to revert my patch that reintroduced the --XXX-neon flags in a week or so. Bert
Re: svn commit: r1349944 - /subversion/trunk/gen-make.py
On Wed, Jun 13, 2012 at 6:10 PM, rhuij...@apache.org wrote: Author: rhuijben Date: Wed Jun 13 16:10:25 2012 New Revision: 1349944 URL: http://svn.apache.org/viewvc?rev=1349944view=rev Log: * gen-make.py Make the --with-neon= and --without-neon arguments on gen-make.py optional, just like how ./configure handles those. Windows doesn't use ./configure and this breaks tools that are friendly enough to provide hints. I don't like this change. ./configure *doesn't* work this way: it errors when attempting to provide the now-defunct neon options. Neon is gone, dead, buried. We shouldn't be special casing it in this manner: people who rely on neon will have more work to do than just updating their scripts, and we don't need to coddle them along the way. -Hyrum Modified: subversion/trunk/gen-make.py Modified: subversion/trunk/gen-make.py URL: http://svn.apache.org/viewvc/subversion/trunk/gen-make.py?rev=1349944r1=1349943r2=1349944view=diff == --- subversion/trunk/gen-make.py (original) +++ subversion/trunk/gen-make.py Wed Jun 13 16:10:25 2012 @@ -257,6 +257,13 @@ if __name__ == '__main__': 'disable-shared', 'installed-libs=', 'vsnet-version=', + + # Keep distributions that help by adding a path + # working. On unix this would be filtered by + # configure, but on Windows gen-make.py is used + # directly. + 'with-neon=', + 'without-neon', ]) if len(args) 1: _usage_exit(Too many arguments) @@ -281,6 +288,9 @@ if __name__ == '__main__': if opt != '--debug': rest.add(opt, val) del prev_conf + elif opt == '--with-neon' or opt == '--without-neon': + # Provide a warning that we ignored these arguments + print(Ignoring no longer supported argument '%s' % opt) else: rest.add(opt, val) -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com/
Re: svn commit: r1349944 - /subversion/trunk/gen-make.py
On 06/13/2012 07:36 PM, Hyrum K Wright wrote: On Wed, Jun 13, 2012 at 6:10 PM, rhuij...@apache.org wrote: Author: rhuijben Date: Wed Jun 13 16:10:25 2012 New Revision: 1349944 URL: http://svn.apache.org/viewvc?rev=1349944view=rev Log: * gen-make.py Make the --with-neon= and --without-neon arguments on gen-make.py optional, just like how ./configure handles those. Windows doesn't use ./configure and this breaks tools that are friendly enough to provide hints. I don't like this change. ./configure *doesn't* work this way: it errors when attempting to provide the now-defunct neon options. Perhaps Bert meant only that, in general, configure allows you to specify options that it doesn't itself understand (while printing a warning about this fact). -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: svn commit: r1349944 - /subversion/trunk/gen-make.py
C. Michael Pilato wrote on Wed, Jun 13, 2012 at 21:33:53 +0200: On 06/13/2012 07:36 PM, Hyrum K Wright wrote: On Wed, Jun 13, 2012 at 6:10 PM, rhuij...@apache.org wrote: Author: rhuijben Date: Wed Jun 13 16:10:25 2012 New Revision: 1349944 URL: http://svn.apache.org/viewvc?rev=1349944view=rev Log: * gen-make.py Make the --with-neon= and --without-neon arguments on gen-make.py optional, just like how ./configure handles those. Windows doesn't use ./configure and this breaks tools that are friendly enough to provide hints. I don't like this change. ./configure *doesn't* work this way: it errors when attempting to provide the now-defunct neon options. Perhaps Bert meant only that, in general, configure allows you to specify options that it doesn't itself understand (while printing a warning about this fact). That's only because we pass such options to APR... and I presume APR's configure would error on option that _it_ doesn't recognize?
RE: svn commit: r1349944 - /subversion/trunk/gen-make.py
-Original Message- From: C. Michael Pilato [mailto:cmpil...@collab.net] Sent: Wednesday, June 13, 2012 9:34 PM To: dev@subversion.apache.org Cc: Hyrum K Wright; comm...@subversion.apache.org Subject: Re: svn commit: r1349944 - /subversion/trunk/gen-make.py On 06/13/2012 07:36 PM, Hyrum K Wright wrote: On Wed, Jun 13, 2012 at 6:10 PM, rhuij...@apache.org wrote: Author: rhuijben Date: Wed Jun 13 16:10:25 2012 New Revision: 1349944 URL: http://svn.apache.org/viewvc?rev=1349944view=rev Log: * gen-make.py Make the --with-neon= and --without-neon arguments on gen-make.py optional, just like how ./configure handles those. Windows doesn't use ./configure and this breaks tools that are friendly enough to provide hints. I don't like this change. ./configure *doesn't* work this way: it errors when attempting to provide the now-defunct neon options. Perhaps Bert meant only that, in general, configure allows you to specify options that it doesn't itself understand (while printing a warning about this fact). I think most distributions at least share some build code between versions. The buildbots only have a single set of dependencies for all the branches we are building. Only once we released 1.9.0 neon will be gone and before that we still have to support it (and even after that we still have to support all the Subversion 1.0-1.7 clients that still use neon) Things get very easy if you just break the few remaining buildbots without caring about the consequences, but it doesn’t make Subversion a better product. Bert
Re: svn commit: r1349944 - /subversion/trunk/gen-make.py
On Wed, Jun 13, 2012 at 9:45 PM, Bert Huijben b...@qqmail.nl wrote: -Original Message- From: C. Michael Pilato [mailto:cmpil...@collab.net] Sent: Wednesday, June 13, 2012 9:34 PM To: dev@subversion.apache.org Cc: Hyrum K Wright; comm...@subversion.apache.org Subject: Re: svn commit: r1349944 - /subversion/trunk/gen-make.py On 06/13/2012 07:36 PM, Hyrum K Wright wrote: On Wed, Jun 13, 2012 at 6:10 PM, rhuij...@apache.org wrote: Author: rhuijben Date: Wed Jun 13 16:10:25 2012 New Revision: 1349944 URL: http://svn.apache.org/viewvc?rev=1349944view=rev Log: * gen-make.py Make the --with-neon= and --without-neon arguments on gen-make.py optional, just like how ./configure handles those. Windows doesn't use ./configure and this breaks tools that are friendly enough to provide hints. I don't like this change. ./configure *doesn't* work this way: it errors when attempting to provide the now-defunct neon options. Perhaps Bert meant only that, in general, configure allows you to specify options that it doesn't itself understand (while printing a warning about this fact). I think most distributions at least share some build code between versions. The buildbots only have a single set of dependencies for all the branches we are building. Only once we released 1.9.0 neon will be gone and before that we still have to support it (and even after that we still have to support all the Subversion 1.0-1.7 clients that still use neon) So, what you're saying is that we have single slaves, with single sets of scripts building multiple branches. And because of this, we can't change the dependencies or script arguments on trunk, for fear of breaking other branches. That sounds a bit like the tail wagging the dog. What would happen if we added a flag on trunk that one of the slaves needed to build, but didn't exist (and hence error'd) on other branches? Would we need to backport that flag as a no-op, simply to make the build slaves happen? That's exactly what this commit does, only in the forward direction. Things get very easy if you just break the few remaining buildbots without caring about the consequences, but it doesn’t make Subversion a better product. Making decisions simply to please the bots doesn't make Subversion a better product, either. They exist to help facilitate development. If there is a problem with the bots, then FIX THE BOTS, rather than introducing hacks in an attempt to please them. In this specific case that might mean a slightly more complex setup, which build each branch with a separate set of dependencies / scripts / inputs, since that's what end users will be doing anyway. -Hyrum -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com/
RE: svn commit: r1349944 - /subversion/trunk/gen-make.py
-Original Message- From: Hyrum K Wright [mailto:hyrum.wri...@wandisco.com] Sent: Thursday, June 14, 2012 12:33 AM To: Bert Huijben Cc: Michael Pilato; Subversion Development Subject: Re: svn commit: r1349944 - /subversion/trunk/gen-make.py On Wed, Jun 13, 2012 at 9:45 PM, Bert Huijben b...@qqmail.nl wrote: -Original Message- From: C. Michael Pilato [mailto:cmpil...@collab.net] Sent: Wednesday, June 13, 2012 9:34 PM To: dev@subversion.apache.org Cc: Hyrum K Wright; comm...@subversion.apache.org Subject: Re: svn commit: r1349944 - /subversion/trunk/gen-make.py On 06/13/2012 07:36 PM, Hyrum K Wright wrote: On Wed, Jun 13, 2012 at 6:10 PM, rhuij...@apache.org wrote: Author: rhuijben Date: Wed Jun 13 16:10:25 2012 New Revision: 1349944 URL: http://svn.apache.org/viewvc?rev=1349944view=rev Log: * gen-make.py Make the --with-neon= and --without-neon arguments on gen- make.py optional, just like how ./configure handles those. Windows doesn't use ./configure and this breaks tools that are friendly enough to provide hints. I don't like this change. ./configure *doesn't* work this way: it errors when attempting to provide the now-defunct neon options. Perhaps Bert meant only that, in general, configure allows you to specify options that it doesn't itself understand (while printing a warning about this fact). I think most distributions at least share some build code between versions. The buildbots only have a single set of dependencies for all the branches we are building. Only once we released 1.9.0 neon will be gone and before that we still have to support it (and even after that we still have to support all the Subversion 1.0-1.7 clients that still use neon) So, what you're saying is that we have single slaves, with single sets of scripts building multiple branches. And because of this, we can't change the dependencies or script arguments on trunk, for fear of breaking other branches. That sounds a bit like the tail wagging the dog. What would happen if we added a flag on trunk that one of the slaves needed to build, but didn't exist (and hence error'd) on other branches? Would we need to backport that flag as a no-op, simply to make the build slaves happen? That's exactly what this commit does, only in the forward direction. Things get very easy if you just break the few remaining buildbots without caring about the consequences, but it doesn’t make Subversion a better product. Making decisions simply to please the bots doesn't make Subversion a better product, either. They exist to help facilitate development. If there is a problem with the bots, then FIX THE BOTS, rather than introducing hacks in an attempt to please them. In this specific case that might mean a slightly more complex setup, which build each branch with a separate set of dependencies / scripts / inputs, since that's what end users will be doing anyway. Well, maybe you could help writing these scripts instead of breaking them because they have to broken anyway in the future. Breaking them 2 minutes after telling you that breaking them will cause huge problems that take much time to solve isn't helping things. Why do you prefer 2 of the 3 buildbots to be broken for at least the rest of the hackathon? Fixing the scripts for the bots, for SharpSvn, for the Slik distribution, for CollabNet's build and several test scenarios takes time certainly more time than the 5 minutes you provided. And probably more than a few weeks if I'm not delaying other work, which I would have to do if as all my build environments are broken by this change. Bert
