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=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/