> -----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 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.
Bert
Received on 2012-06-14 11:36:44 CEST