i2space provides Best travel services on Travel Portal India
Travel Portal India – i2space.com is a leading online travel portal in India. We provide Travel portal Development to travel consultation, searching for trip plans, seat layout, providing customized tour packages, booking tickets, etc. For more details please visit our website http://www.i2space.com/onlinetravelportal.html or contact us at 9052266440 / 9704536531 Contact Person: Bhargava Mobile no. 9052266440 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using C++0x auto
On Tue, Jul 16, 2013 at 04:17:50PM +0900, Mike Hommey wrote: > On Sat, Jul 13, 2013 at 01:15:31PM -0700, Kyle Huey wrote: > > We've dropped support for versions of MSVC prior to 2010, and we're > > requiring at least GCC 4.4. According to [0] that means we should > > be able to use *auto*. Anybody know any reasons why we can't start > > using it? > > Filed bug 894242. (double 42!) This almost stuck, but B2G desktop builds are, guess what, using gcc 4.4, and a bug was already on file to upgrade that (bug 770625). Hopefully this will go forward now that there are patches. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Shutting off leak tests?
On 7/17/2013 2:05 AM, Jesse Ruderman wrote: > > AWSY is not a replacement for shutdown-leak testing. It's limited to code > exercised by TP5. Small leaks are masked by normal variation in memory use. > > Note, though, that we still run almost all of our test suites on debug builds with leak checking enabled, so we catch shutdown leaks in all the Mochitest variants, reftest and crashtest. The actual "leak test" is much simpler, it just loads a few web pages and quits. The only valuable thing we're losing from shutting this off is tracemalloc coverage, which we don't have elsewhere. I don't have any evidence to show that anyone has actually looked at the tracemalloc data or done anything useful with it in recent history, though. Leaks discovered by tracemalloc don't make the test fail, so we're not measuring much there. -Ted ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Three RDFa-related W3C Proposed (Edited) Recommendations
I've only quickly glanced at those, and I haven't followed those discussions at all, I have to admit. Are there any practical consequences for gecko/firefox? It doesn't look like it would, in particular when looking at the reference implementations being all on top of html platforms. Axel On 7/17/13 1:12 AM, L. David Baron wrote: The W3C has released three RDFA-related documents, one proposed recommendation: HTML+RDFa 1.1: http://www.w3.org/TR/2013/PR-html-rdfa-20130625/ and two proposed edited recommendations (which contain only editorial changes): RDFa 1.1 Core: http://www.w3.org/TR/2013/PER-rdfa-core-20130625/ XHTML+RDFa 1.1 http://www.w3.org/TR/2013/PER-xhtml-rdfa-20130625/ There's a call for review to W3C member companies (of which Mozilla is one) open until Tuesday, July 23 (one week from today). If there are comments you think Mozilla should send as part of the review, or if you think Mozilla should voice support or opposition to the specification, please say so in this thread. (I'd note, however, that there have been many previous opportunities to make comments, so it's somewhat bad form to bring up fundamental issues for the first time at this stage.) There was one formal objection earlier in the process, whose history is documented in http://lists.w3.org/Archives/Public/public-rdfa-wg/2013Jan/0057.html -David ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Three RDFa-related W3C Proposed (Edited) Recommendations
On 7/16/2013 7:12 PM, L. David Baron wrote: The W3C has released three RDFA-related documents, one proposed recommendation: HTML+RDFa 1.1: http://www.w3.org/TR/2013/PR-html-rdfa-20130625/ If there are comments you think Mozilla should send as part of the review, or if you think Mozilla should voice support or opposition to the specification, please say so in this thread. (I'd note, however, that there have been many previous opportunities to make comments, so it's somewhat bad form to bring up fundamental issues for the first time at this stage.) Reading through the spec, it appears that it doesn't substantively change HTML parsing behavior unless HTML+RDFa "document conformance is required". As far as I know, we do not intend to implement this specification and therefore have no reason to comment on it. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Update: Engineering meeting locations
I'll keep this short. There are changes to the meeting locations for the Engineering/Platform (Tue, 11am PT) meeting. SFO: Warfield (change to provide more space) TOR: Finch (change to avoid conflict with TOR Commons) MTV: Warp Core (no change) Remote: Engineering Vidyo room (no change) Lawrence ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Shutting off leak tests?
On 7/17/2013 4:26 AM, Ted Mielczarek wrote: The only valuable thing we're losing from shutting this off is tracemalloc coverage, which we don't have elsewhere. I don't have any evidence to show that anyone has actually looked at the tracemalloc data or done anything useful with it in recent history, though. Leaks discovered by tracemalloc don't make the test fail, so we're not measuring much there. Trace Malloc measures three things: leaks, max heap size, and number of allocations. All of these are reported to the graph server and use the same monitoring as Talos benchmarks. Like Talos data, this data does not have a consistent process or owner responsible for watching it or improving it, but there are some people who watch for alerts from the monitoring script and try to investigate regressions. Trace Malloc Leaks is a fairly stable measurement; our monitoring has not found regressions in it very often, but it does occasionally (about once a year?) help alert us to an actionable bug that might have been harder to fix otherwise. The latest example is: https://bugzilla.mozilla.org/show_bug.cgi?id=872947 Trace Malloc MaxHeap is somewhat useful, but largely overlaps with the measurements produced by AWSY and Tp5, both of which are probably more useful and representative. Trace Malloc Allocs is not very useful from what I understand; a change in this benchmark does not necessarily correlate with any user-visible change. So the main thing we'd lose is graph server monitoring of Trace Malloc Leaks. This is occasionally useful, but in a limited way because the monitoring process is unowned, and because the current value of the benchmark is high enough that small changes are ignored by the monitoring system. It has some chance of sometimes making large regressions easier to detect. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Shutting off leak tests?
> So the main thing we'd lose is graph server monitoring of Trace Malloc Leaks. > This is occasionally useful, but in a limited way because the monitoring > process is unowned, and because the current value of the benchmark is high > enough that small changes are ignored by the monitoring system. It has some > chance of sometimes making large regressions easier to detect. In that case, is consensus that by disabling these tests we're only taking on minimal pain when investigating major leak regressions, and that we think those leaks will still be obvious through other feedback? If so, +1 to the proposal. -Alex On Jul 17, 2013, at 10:54 AM, Matt Brubeck wrote: > On 7/17/2013 4:26 AM, Ted Mielczarek wrote: >> The only valuable thing we're losing from shutting this off is >> tracemalloc coverage, which we don't have elsewhere. I don't have any >> evidence to show that anyone has actually looked at the tracemalloc data >> or done anything useful with it in recent history, though. Leaks >> discovered by tracemalloc don't make the test fail, so we're not >> measuring much there. > > Trace Malloc measures three things: leaks, max heap size, and number of > allocations. All of these are reported to the graph server and use the same > monitoring as Talos benchmarks. Like Talos data, this data does not have a > consistent process or owner responsible for watching it or improving it, but > there are some people who watch for alerts from the monitoring script and try > to investigate regressions. > > Trace Malloc Leaks is a fairly stable measurement; our monitoring has not > found regressions in it very often, but it does occasionally (about once a > year?) help alert us to an actionable bug that might have been harder to fix > otherwise. The latest example is: > https://bugzilla.mozilla.org/show_bug.cgi?id=872947 > > Trace Malloc MaxHeap is somewhat useful, but largely overlaps with the > measurements produced by AWSY and Tp5, both of which are probably more useful > and representative. > > Trace Malloc Allocs is not very useful from what I understand; a change in > this benchmark does not necessarily correlate with any user-visible change. > > So the main thing we'd lose is graph server monitoring of Trace Malloc Leaks. > This is occasionally useful, but in a limited way because the monitoring > process is unowned, and because the current value of the benchmark is high > enough that small changes are ignored by the monitoring system. It has some > chance of sometimes making large regressions easier to detect. > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Proposal: requiring build peer review for Makefile.in changes
Traditionally, it's been very difficult for the build peers to keep on top of changes in the build config because changes are occurring on bug components we don't follow, are touching files all over the tree, and because build peers aren't always asked for review. The potential for "sneaking" things past build peer review has resulted in a number of self-inflicted wounds, the Fennec build rules probably being the best example (the dependencies are all wrong and no-op builds take ~16s when they should take 1 or 2s). This history contributed to us implementing a more strict "sandbox" in moz.build files: take away as many footguns as possible and there will be less self-inflicted wounds. Unfortunately, the moz.build conversion isn't finished and it will drag on for a while. There will still be Makefile.in in the tree and that leaves the door open for new badness. I would like to reinforce the existing policy: *if you are changing a Makefile.in, please ask a build peer for review unless the change is just adding or removing to an existing list.* For the most part, people have been abiding by this policy. However, things are still creeping through. Unfortunately, some of them wouldn't get r+ from a build peer. Since new Makefile.in badness makes people's lives harder (especially when it makes the build slower), I would like to propose a more strict policy around Makefile.in changes: *if a non-list change in a Makefile.in isn't reviewed by a build peer, it doesn't land or gets backed out.* This could potentially be enforced with repository push hooks. I /think/ this proposal is supported by our module governance system since Makefile.in are the purview of the build config module. But I wanted to run the proposal by people to make sure it is generally well-received and there aren't any major concerns. Gregory ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: requiring build peer review for Makefile.in changes
The flip side of this, of course, is that build peers need to ensure that they are not the long pole in reviews. But I presume you guys are prepared to turn around these additional reviews quickly, otherwise you wouldn't have asked for the extra load. On Wed, Jul 17, 2013 at 5:00 PM, Gregory Szorc wrote: > Traditionally, it's been very difficult for the build peers to keep on > top of changes in the build config because changes are occurring on bug > components we don't follow, are touching files all over the tree, and > because build peers aren't always asked for review. > > The potential for "sneaking" things past build peer review has resulted > in a number of self-inflicted wounds, the Fennec build rules probably > being the best example (the dependencies are all wrong and no-op builds > take ~16s when they should take 1 or 2s). > > This history contributed to us implementing a more strict "sandbox" in > moz.build files: take away as many footguns as possible and there will > be less self-inflicted wounds. > > Unfortunately, the moz.build conversion isn't finished and it will drag > on for a while. There will still be Makefile.in in the tree and that > leaves the door open for new badness. > > I would like to reinforce the existing policy: *if you are changing a > Makefile.in, please ask a build peer for review unless the change is > just adding or removing to an existing list.* > > For the most part, people have been abiding by this policy. However, > things are still creeping through. Unfortunately, some of them wouldn't > get r+ from a build peer. > > Since new Makefile.in badness makes people's lives harder (especially > when it makes the build slower), I would like to propose a more strict > policy around Makefile.in changes: *if a non-list change in a > Makefile.in isn't reviewed by a build peer, it doesn't land or gets > backed out.* This could potentially be enforced with repository push hooks. > > I /think/ this proposal is supported by our module governance system > since Makefile.in are the purview of the build config module. But I > wanted to run the proposal by people to make sure it is generally > well-received and there aren't any major concerns. > > Gregory > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: requiring build peer review for Makefile.in changes
On 7/17/2013 5:24 PM, Justin Lebar wrote: > The flip side of this, of course, is that build peers need to ensure > that they are not the long pole in reviews. But I presume you guys > are prepared to turn around these additional reviews quickly, > otherwise you wouldn't have asked for the extra load. I believe we're ready to handle it, yes. If we're not, we can revert the policy if it becomes an issue. One concern I do have is some people like to land patches before deadlines and the build peers don't find out about large build changes until it's a fire drill. Build could thus become the long pole if we insist on correctness over done. A solution here is to CC and f? us on bugs long before final review. Perhaps a keyword or whiteboard entry could attract our attention as well? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Reminder: in-tree mozconfigs are not for developers
Hi, As it seems there is a trend towards using in-tree mozconfigs for local developer builds, I think a reminder is in order: In-tree mozconfigs are for buildbot consumption. For Firefox desktop builds, a mozconfig should be unnecessary for most people, except if their compiler is not at a standard location. If that doesn't work for you, try running ./mach bootstrap at the root of the mozilla source tree. If that still doesn't build after that, please try asking on the #build irc channel or file a bug in the Core::Build Config component. For Firefox for Android builds, a mozconfig is necessary, but it only needs to contain the following: ac_add_options --enable-application=mobile/android ac_add_options --target=arm-linux-androideabi ac_add_options --with-android-ndk=/path/to/ndk ac_add_options --with-android-sdk=/path/to/sdk (the target varies for x86 android builds, and the addition of "ac_add_options --with-arch=armv6" is required for armv6 builds) If the mozconfig above doesn't work for you, double check the instructions on https://wiki.mozilla.org/Mobile/Fennec/Android#Building_Fennec specifically, that you have all the build dependencies installed (eventually, this should make it into mach bootstrap, see bug 844838), and if that still doesn't work, please try asking on the #build irc channel or file a bug in the Core::Build Config component. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reminder: in-tree mozconfigs are not for developers
On Thu, Jul 18, 2013 at 10:51:10AM +0900, Mike Hommey wrote: > Hi, > > As it seems there is a trend towards using in-tree mozconfigs for > local developer builds, I think a reminder is in order: > > In-tree mozconfigs are for buildbot consumption. > > For Firefox desktop builds, a mozconfig should be unnecessary for most > people, except if their compiler is not at a standard location. > > If that doesn't work for you, try running ./mach bootstrap at the root > of the mozilla source tree. If that still doesn't build after that, > please try asking on the #build irc channel or file a bug in the > Core::Build Config component. > > For Firefox for Android builds, a mozconfig is necessary, but it only > needs to contain the following: ac_add_options > --enable-application=mobile/android ac_add_options > --target=arm-linux-androideabi ac_add_options > --with-android-ndk=/path/to/ndk ac_add_options > --with-android-sdk=/path/to/sdk > > (the target varies for x86 android builds, and the addition of > "ac_add_options --with-arch=armv6" is required for armv6 builds) > > If the mozconfig above doesn't work for you, double check the > instructions on > https://wiki.mozilla.org/Mobile/Fennec/Android#Building_Fennec > specifically, that you have all the build dependencies installed > (eventually, this should make it into mach bootstrap, see bug 844838), > and if that still doesn't work, please try asking on the #build irc > channel or file a bug in the Core::Build Config component. As Boris noted on irc, there is room for flexibility. You may require ac_add_options --enable-debug, and you may want to use ac_add_options --with-ccache. There are a few other options you can use in a mozconfig, But the bottom-line is minimalistic mozconfigs should be enough for everyone, and in-tree mozconfigs should be left alone. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: requiring build peer review for Makefile.in changes
I'm probably responsible for those Fennec build files (if they were correct, it would have been blassey). In any case, we probably did 'sneak' things past build peers. Not intentionally, of course. We were more worried about getting a product into the marketplace that didn't suck than the correctness of our make files. We cut corners, and we'd probably do it again given the circumstances. Thanks for cleaning up our mess! Gregory Szorc wrote: Traditionally, it's been very difficult for the build peers to keep on top of changes in the build config because changes are occurring on bug components we don't follow, are touching files all over the tree, and because build peers aren't always asked for review. The potential for "sneaking" things past build peer review has resulted in a number of self-inflicted wounds, the Fennec build rules probably being the best example (the dependencies are all wrong and no-op builds take ~16s when they should take 1 or 2s). This history contributed to us implementing a more strict "sandbox" in moz.build files: take away as many footguns as possible and there will be less self-inflicted wounds. Unfortunately, the moz.build conversion isn't finished and it will drag on for a while. There will still be Makefile.in in the tree and that leaves the door open for new badness. I would like to reinforce the existing policy: *if you are changing a Makefile.in, please ask a build peer for review unless the change is just adding or removing to an existing list.* For the most part, people have been abiding by this policy. However, things are still creeping through. Unfortunately, some of them wouldn't get r+ from a build peer. Since new Makefile.in badness makes people's lives harder (especially when it makes the build slower), I would like to propose a more strict policy around Makefile.in changes: *if a non-list change in a Makefile.in isn't reviewed by a build peer, it doesn't land or gets backed out.* This could potentially be enforced with repository push hooks. I /think/ this proposal is supported by our module governance system since Makefile.in are the purview of the build config module. But I wanted to run the proposal by people to make sure it is generally well-received and there aren't any major concerns. Gregory ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reminder: in-tree mozconfigs are not for developers
On Wed, Jul 17, 2013 at 6:51 PM, Mike Hommey wrote: > Hi, > > As it seems there is a trend towards using in-tree mozconfigs for local > developer builds, I think a reminder is in order: > > In-tree mozconfigs are for buildbot consumption. > > For Firefox desktop builds, a mozconfig should be unnecessary for most > people, except if their compiler is not at a standard location. > Did you mean "should not be" here? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reminder: in-tree mozconfigs are not for developers
On Wed, Jul 17, 2013 at 10:29:01PM -0700, Dave Townsend wrote: > On Wed, Jul 17, 2013 at 6:51 PM, Mike Hommey wrote: > > > Hi, > > > > As it seems there is a trend towards using in-tree mozconfigs for > > local developer builds, I think a reminder is in order: > > > > In-tree mozconfigs are for buildbot consumption. > > > > For Firefox desktop builds, a mozconfig should be unnecessary for > > most people, except if their compiler is not at a standard location. > > > > Did you mean "should not be" here? should be unnecessary, or should not be necessary. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: requiring build peer review for Makefile.in changes
The proposal sounds good to me but I guess you wouldn't want to be notified of every small addition/change to Makefiles in test directories? I suppose you're targeting actual changes to dependencies etc, but where do we draw the line? Can we maybe add a push hook intelligent enough to separate actual changes from minor changes that don't need build peer review by scanning for certain keywords? - Tim On 07/18/2013 02:00 AM, Gregory Szorc wrote: > Traditionally, it's been very difficult for the build peers to keep on > top of changes in the build config because changes are occurring on bug > components we don't follow, are touching files all over the tree, and > because build peers aren't always asked for review. > > The potential for "sneaking" things past build peer review has resulted > in a number of self-inflicted wounds, the Fennec build rules probably > being the best example (the dependencies are all wrong and no-op builds > take ~16s when they should take 1 or 2s). > > This history contributed to us implementing a more strict "sandbox" in > moz.build files: take away as many footguns as possible and there will > be less self-inflicted wounds. > > Unfortunately, the moz.build conversion isn't finished and it will drag > on for a while. There will still be Makefile.in in the tree and that > leaves the door open for new badness. > > I would like to reinforce the existing policy: *if you are changing a > Makefile.in, please ask a build peer for review unless the change is > just adding or removing to an existing list.* > > For the most part, people have been abiding by this policy. However, > things are still creeping through. Unfortunately, some of them wouldn't > get r+ from a build peer. > > Since new Makefile.in badness makes people's lives harder (especially > when it makes the build slower), I would like to propose a more strict > policy around Makefile.in changes: *if a non-list change in a > Makefile.in isn't reviewed by a build peer, it doesn't land or gets > backed out.* This could potentially be enforced with repository push hooks. > > I /think/ this proposal is supported by our module governance system > since Makefile.in are the purview of the build config module. But I > wanted to run the proposal by people to make sure it is generally > well-received and there aren't any major concerns. > > Gregory > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > -- Tim Taubert Firefox Engineer ttaub...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
