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.

-Hyrum

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/