Should we update /gfx/cairo/cairo/INSTALL too, or is that an "upstream" file?

AGAIN, PLEASE LOOK AT TINDERBOX BEFORE PUSHING AND DO NOT PUSH ON UNSTARRED ORANGE.

Comment on attachment 528351 [details] [diff] [review] (Av1) Jut remove them [Checked in: Comment 2] http://hg.mozilla.org/mozilla-central/rev/1022108defcd

(And yes, you filed bug 652902 after my comment above.)

(In reply to comment #2) > AGAIN, PLEASE LOOK AT TINDERBOX BEFORE PUSHING AND DO NOT PUSH ON UNSTARRED > ORANGE. I did look and I did star. (In reply to comment #4) > (And yes, you filed bug 652902 after my comment above.) Yes, I did file that bug!

You're missing the point of starring -- it's for *known intermittent* oranges. If somebody broke the tree, don't just file a bug, star it, and check in anyway. That's not ok. The next time you do that or something like it I'm going to file a bug requesting that your commit access be revoked.

(In reply to comment #6) > You're missing the point of starring -- it's for *known intermittent* oranges. > If somebody broke the tree, don't just file a bug, star it, and check in > anyway. That's not ok. Maybe it's English humor, but complaining because I did not enough and too much at the same time does not make any sense to me: see bug 652902 comment 4. > The next time you do that or something like it I'm > going to file a bug requesting that your commit access be revoked. Then be sure to remove cleary@mozilla.com's access too for braking the tree in the first place :-|

(In reply to comment #7) > > The next time you do that or something like it I'm > > going to file a bug requesting that your commit access be revoked. > > Then be sure to remove cleary@mozilla.com's access too for braking the tree in > the first place :-| If you spend 5 minutes reading this page <https://developer.mozilla.org/En/Developer_Guide/Committing_Rules_and_Responsibilities>, you'll know that all that we require is for people to watch the tree and hang around on IRC in case something goes wrong. We do not have a policy to revoke people's commit access for breaking something in a merge for example.

I'm tired of your insistence on interpreting everything you're told to do perfectly literally rather than trying to be a good member of the community, think before you act, and try to understand why the rules are the way they are. When the tree breaks, having other things landing at the same time often interferes with getting things fixed. If you don't understand by this point that it's not ok to check in on orange (and filing a bug on it and pretending it's intermittent doesn't help) you shouldn't have commit access.

(In reply to comment #9) > I'm tired of your insistence on interpreting everything you're told to do > perfectly literally rather than trying to be a good member of the community, > think before you act, and try to understand why the rules are the way they are. (And when things aren't clear, ask on #developers.)

+1 to what dbaron said. This isn't the first, second, or even third time your checkins have broken the rules and/or caused problems. The core expectation that comes with having commit access is that people will understand and follow the rules/guidelines for the tree. Indeed, the commit access policy specifically mentions the risk of "giving the untrustworthy or incompetent power to mess things up." To put it more bluntly, I think you need to examine your history here and adjust your commit behavior so it stops being a problem. If you're unable to do so, the next step is having your commit access revoked. I hope we can avoid that, but if that's what it takes then so be it.

See comment 1.

Comment on attachment 528505 [details] [diff] [review] (Bv1) Remove the one in cairo too Er, what? This --disable-svg is from cairo's configure, which we don't even use (this is from an upstream INSTALL file). It disables the cairo svg surface, and has nothing to do with mozilla's disable-svg switch.