Last Comment Bug 652862 - Remove disable-svg references in tests
: Remove disable-svg references in tests
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Build Config (show other bugs)
: Trunk
: All All
: -- trivial (vote)
: mozilla6
Assigned To: Serge Gautherie (:sgautherie)
:
Mentors:
http://mxr.mozilla.org/mozilla-centra...
Depends on: 585020
Blocks:
  Show dependency treegraph
 
Reported: 2011-04-26 10:37 PDT by Serge Gautherie (:sgautherie)
Modified: 2011-05-07 11:07 PDT (History)
4 users (show)
bugzillamozillaorg_serge_20140323: in‑testsuite-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
(Av1) Jut remove them [Checked in: Comment 2] (2.48 KB, patch)
2011-04-26 10:45 PDT, Serge Gautherie (:sgautherie)
dbaron: review+
Details | Diff | Splinter Review
(Bv1) Remove the one in cairo too (825 bytes, patch)
2011-04-26 19:04 PDT, Serge Gautherie (:sgautherie)
vladimir: review-
Details | Diff | Splinter Review

Description Serge Gautherie (:sgautherie) 2011-04-26 10:37:56 PDT

    
Comment 1 Serge Gautherie (:sgautherie) 2011-04-26 10:45:43 PDT
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?
Comment 2 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2011-04-26 11:59:59 PDT
AGAIN, PLEASE LOOK AT TINDERBOX BEFORE PUSHING AND DO NOT PUSH ON UNSTARRED ORANGE.
Comment 3 Serge Gautherie (:sgautherie) 2011-04-26 12:06:01 PDT
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+2 (mostly busy through August 4; review requests must explain patch) 2011-04-26 12:06:11 PDT
(And yes, you filed bug 652902 after my comment above.)
Comment 5 Serge Gautherie (:sgautherie) 2011-04-26 12:10:10 PDT
(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+2 (mostly busy through August 4; review requests must explain patch) 2011-04-26 12:52:33 PDT
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) 2011-04-26 13:02:02 PDT
(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 :-|
Comment 8 :Ehsan Akhgari 2011-04-26 14:32:33 PDT
(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.
Comment 9 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2011-04-26 16:07:13 PDT
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+2 (mostly busy through August 4; review requests must explain patch) 2011-04-26 16:11:11 PDT
(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] 2011-04-26 16:40:53 PDT
+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) 2011-04-26 19:04:52 PDT
Created attachment 528505 [details] [diff] [review]
(Bv1) Remove the one in cairo too

See comment 1.
Comment 13 Vladimir Vukicevic [:vlad] [:vladv] 2011-05-06 15:07:57 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.