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.wright_at_wandisco.com> wrote:
> 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/
Received on 2012-06-14 10:44:54 CEST