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=1349944&view=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/