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

On Thu, Jun 14, 2012 at 11:36 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Greg Stein [mailto:gstein_at_gmail.com]
>> Sent: Thursday, June 14, 2012 10:44 AM
>> To: Bert Huijben; Hyrum K Wright
>> Cc: dev_at_subversion.apache.org
>> Subject: Re: svn commit: r1349944 - /subversion/trunk/gen-make.py
>>
>> 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.
>
> Ok, maybe the response might have been:
>
> We should wait a few days before breaking every Windows Subversion
> development environment to allow them to be fixed first.
>
> I spent most of the night to get things fixed. (Last commit after 3 AM, and
> the final fixes on the buildbot after I woke up)
>
> But I don't understand why somebody just commits a change that he knows
> break things for at least two other developers on the same table. (I had to
> fix Markus development environment too, as he couldn't test the work he was
> working on)
>
> Most unix developers just assume that looking in a system library to find
> things like apr, serf, neon etc. works on all systems.
>
> Windows is by default not a development environment, so there is no standard
> place to look for these things and to work stable we pass explicit
> arguments. Just removing the arguments without notice is breaking things
> directly without a way to recover using the normal routing..
>
> Just like breaking you development svn for commits or reverts breaks your
> entire workflow.
>
>
> I explicitly told Hyrum to wait with this specific change, as this impacts
> more people than all the other removal he did. And instead of providing some
> time or discussing this change on list he just broke things for me and
> others depending on these flags.

I'm sorry about that. I heard "you forgot this part of nuking neon"
so I attempted to rectify that change. I realized it would cause
breakage (as prior neon changes did for *nix environments), but did
not expect them to be large.

> I don't care that this flag will be gone with 1.8, we can catch up well
> before that. And I think for most my cases I did, but maybe others need some
> time too.
>
> This is not just about the buildbots, this is about workflows that are just
> broken beyond repair without notice.
>
>
> I would have liked to have some time to fix things before everything that
> depends on it breaks down. I noted the problem as I assumed that he didn't
> know about things relying on them and he explicitly used that information to
> apply this as a change that 'he forgot about'.
>
> This is just working against other developers. And this entire thread delays
> things more.
>
> Feel free to revert my patch that reintroduced the --XXX-neon flags in a
> week or so.

Thank you for the complete response.

I wasn't trying to be vindictive or penalizing Windows, just cleaning
up what I perceived to be my own mess. As a non-development platform,
Windows probably doesn't get enough love, and those of us who don't
use it regularly probably do not appreciate the difficulty in doing
so.

-Hyrum

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