On Wed, May 18, 2011 at 1:48 AM, Bert Huijben <b...@qqmail.nl> wrote: >> -----Original Message----- >> From: Hyrum K Wright [mailto:hy...@hyrumwright.org] >> Sent: woensdag 18 mei 2011 1:11 >> To: dev@subversion.apache.org >> Cc: comm...@subversion.apache.org >> Subject: Re: svn commit: r1104610 - in >> /subversion/trunk/subversion/libsvn_wc: props.c wc_db.c wc_db.h >> >> I understand the desire to get the buildbots green again, and I'm >> sorry these revisions which I committed broke the bots, but a little >> patience might have been useful here. We have a long tradition of >> allowing folks to attempt to fix problems, rather than reverting their >> commits without consultation. I kinda wish you'd have given me >> another 12 hours to attempt to fix it, rather than reverting. > > We also have the generic rule that any committer (full or partial) may > revert something that makes it impossible for them to do further > development. (See hacking)
No, we have a policy that people can revert changes to the *build system* which prevent productivity: "To prevent loss of productivity, any committer (full or partial) can immediately revert any build system change that breaks their ability to effectively do development on their platform of choice, as a matter of ordinary routing, without fear of accusations of an over-reaction." (From: http://subversion.apache.org/docs/community-guide/building.html#configury ) I'm not trying to play process obstructionist, just noting that a mail mentioning the breakage and indicating your intent to revert would have been a nice consideration. > And tomorrow morning the asf repository will be readonly for quite some > time, so waiting till after that will probably cause more delays. > > Besides, you just mailed that you weren't going to fix this issue... :-) I guess I should have been more clear: I'm happy to fix my own breakage to the buildbots. When indicating I was moving on to other things, I didn't know I'd broken the test world. > Somehow the test that should have picked up the original failure is broken. > It thinks that no output at all for a recursive proplist is ok. > > So two different bugs (the local changes one; and the base-deleted one) > together kept the prop_tests.py 15 test succeeding. Has this bug in the test suite been fixed? If not, I suppose that's a place to start... -Hyrum