Remove disable-svg references in tests

RESOLVED FIXED in mozilla6

Status

()

Core
Build Config
--
trivial
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: sgautherie, Assigned: sgautherie)

Tracking

Trunk
mozilla6
Points:
---
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

Comment hidden (empty)
(Assignee)

Comment 1

6 years ago
Created attachment 528351 [details] [diff] [review]
(Av1) Jut remove them
[Checked in: Comment 2]

Should we update /gfx/cairo/cairo/INSTALL too, or is that an "upstream" file?
Attachment #528351 - Flags: review?(dbaron)
Attachment #528351 - Flags: review?(dbaron) → review+
AGAIN, PLEASE LOOK AT TINDERBOX BEFORE PUSHING AND DO NOT PUSH ON UNSTARRED ORANGE.
(Assignee)

Comment 3

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

http://hg.mozilla.org/mozilla-central/rev/1022108defcd
Attachment #528351 - Attachment description: (Av1) Jut remove them → (Av1) Jut remove them [Checked in: Comment 2]
(And yes, you filed bug 652902 after my comment above.)
(Assignee)

Comment 5

6 years ago
(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.
(Assignee)

Comment 7

6 years ago
(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.
(Assignee)

Comment 12

6 years ago
Created attachment 528505 [details] [diff] [review]
(Bv1) Remove the one in cairo too

See comment 1.
Attachment #528505 - Flags: review?(vladimir)
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.
Attachment #528505 - Flags: review?(vladimir) → review-
(Assignee)

Updated

6 years ago
Attachment #528505 - Attachment is obsolete: true
(Assignee)

Updated

6 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Target Milestone: --- → mozilla6
You need to log in before you can comment on or make changes to this bug.