Re: svn commit: r1349944 - /subversion/trunk/gen-make.py

On Thu, Jun 14, 2012 at 1:23 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Hyrum K Wright [mailto:hyrum.wright_at_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 <bert_at_qqmail.nl> wrote:
>> >
>> >
>> >> -----Original Message-----
>> >> From: C. Michael Pilato [mailto:cmpilato_at_collab.net]
>> >> Sent: Wednesday, June 13, 2012 9:34 PM
>> >> To: dev_at_subversion.apache.org
>> >> Cc: Hyrum K Wright; commits_at_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,  <rhuijben_at_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/