On Thu, Jun 14, 2012 at 11:36 AM, Bert Huijben <b...@qqmail.nl> wrote: > > >> -----Original Message----- >> From: Greg Stein [mailto:gst...@gmail.com] >> Sent: Thursday, June 14, 2012 10:44 AM >> To: Bert Huijben; Hyrum K Wright >> Cc: dev@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/
