> -----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.
Breaking them 2 minutes after telling you that breaking them will cause huge problems that take much time to solve isn't helping things.
Why do you prefer 2 of the 3 buildbots to be broken for at least the rest of the hackathon?
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.
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.
Bert
Received on 2012-06-14 01:24:03 CEST