652862 - Remove disable-svg references in tests

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Comment 1

[Serge Gautherie (:sgautherie)]

Attachment: (Av1) Jut remove them [Checked in: Comment 2]

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

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 3

[Serge Gautherie (:sgautherie)]

Comment on attachment 528351 [details] [diff] [review]
(Av1) Jut remove them
[Checked in: Comment 2]

http://hg.mozilla.org/mozilla-central/rev/1022108defcd

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 5

[Serge Gautherie (:sgautherie)]

(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!

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 7

[Serge Gautherie (:sgautherie)]

(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 [e-mail]'s access too for braking the tree in the first place :-|

Comment 8

[(no longer active)]

(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 [e-mail]'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.

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(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.)

Comment 11

[Justin Dolske [:Dolske]]

+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.

Comment 12

[Serge Gautherie (:sgautherie)]

Attachment: (Bv1) Remove the one in cairo too

See comment 1.

Comment 13

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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.