Re: Toolkit sub-module Preferred Reviewers who are not Toolkit Peers
Ideally you would have talked to the Toolkit module owner (i.e. me) before adding a new chunk of code to it but Toolkit has basically become the wild-west of modules and I'm not sure what purpose an owner is meant to have at this point. The Submodule page is probably hopelessly out of date at this point and I don't know if trying to save it is the right thing to do. On Sun, Jan 19, 2014 at 6:47 PM, Shih-Chiang Chien wrote: > I added a component for captive portal detection about a year ago. Should > I update https://wiki.mozilla.org/Toolkit/Submodules myself? > > Best Regards, > Shih-Chiang Chien > Mozilla Taiwan > > On Jan 20, 2014, at 8:17 AM, Tom Schuster wrote: > > > I refactorted and debugged most of the findbar code. Mike seems to the de > > facto owner, so I think it makes sense for me to do reviews. I doubt > > anybody else knows much about the code. There seems to be no submodule > for > > it anyway? > > On Jan 19, 2014 10:40 PM, "Matthew N." wrote: > > > >> Thanks for clarifying. > >> > >> Myself, Jared Wein, and Paolo Amadini (Download Manager Owner) seem to > be > >> missing from the Toolkit peer list then. > >> > >> Thanks, > >> Matthew > >> > >> On 1/19/14, 8:47 PM, Dave Townsend wrote: > >> > >>> Everyone who is a preferred reviewer should be a peer, if they aren't > it's > >>> likely because I forgot to update the appropriate lists. Who do you see > >>> who > >>> is absent from the peer list? > >>> > >>> > >>> On Sat, Jan 18, 2014 at 11:51 AM, Matthew N. > wrote: > >>> > >>> Hello, > > What does it mean to be a "Preferred Reviewer" (previously called a > "peer") in a Toolkit sub-module[1] and not be on the list of Toolkit > Peers[2]? The Toolkit Code Review page[3] doesn't seem to cover this > case. > > Specifically: > 1) Can a "Preferred Reviewer" review code in the related submodule > without > oversight from the sub-module owner? > 2) Is a sub-module "Preferred Reviewer" considered a "Toolkit > reviewer" > for the purposes of [3]? > > Thanks, > MattN > > [1] https://wiki.mozilla.org/Toolkit/Submodules > [2] https://wiki.mozilla.org/Modules/Toolkit > [3] https://wiki.mozilla.org/Toolkit/Code_Review > ___ > 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 > >> > > ___ > > 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 > > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: CPP_UNIT_TESTS being removed from "make check"
Is there trychooser syntax for just running the cpp tests on a try push? And can http://trychooser.pub.build.mozilla.org/ be updated to include it please? :) Cheers, Chris P. On 1/9/2014 7:00 AM, Ted Mielczarek wrote: Hello, Just a heads up that very soon we'll be removing CPP_UNIT_TESTS from the "make check" target[1]. The tests have been split out into a separate test job on TBPL[2] (labelled Cpp) for almost a month now without issue, and we've also added a mach command--"mach cppunittests"[3]--to facilitate running them locally, so we'd like to stop double-running them on the build machines. Running the tests as a separate job has a lot of nice qualities: the jobs can be retriggered in case of failure, the execution time doesn't tie up a build slave (and thus delay the posting of the build log by buildbot to where TBPL can get it), we can run the tests on Android and B2G, we get better platform coverage on our test slaves than on our build slaves. If you encounter any issues please feel free to file a bug. Regards, -Ted 1. https://bugzilla.mozilla.org/show_bug.cgi?id=949536 2. https://bugzilla.mozilla.org/show_bug.cgi?id=937637 3. https://bugzilla.mozilla.org/show_bug.cgi?id=949538 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Parallel sandboxed iframes
Bill McCloskey writes: >> About the front-end breakages, the ongoing e10s work should help with >> that right? I mean, do we usually make assumptions about what frame the >> content process belongs to, or whether the iframe content process is the >> same as the iframe host content process? > > Unfortunately, we do often make assumptions like that. But once we > make the initial transition to electrolysis, it should just be a > matter of ensuring that messages go to the right process. I don't know > much more than that though, since I haven't looked closely enough at > the patches in bug 879475. >From the front-end point of view there shouldn't be much difference of same process or difference content process using frame message manager, since the detail of communications are hidden under the hood. Kanru ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Toolkit sub-module Preferred Reviewers who are not Toolkit Peers
I added a component for captive portal detection about a year ago. Should I update https://wiki.mozilla.org/Toolkit/Submodules myself? Best Regards, Shih-Chiang Chien Mozilla Taiwan On Jan 20, 2014, at 8:17 AM, Tom Schuster wrote: > I refactorted and debugged most of the findbar code. Mike seems to the de > facto owner, so I think it makes sense for me to do reviews. I doubt > anybody else knows much about the code. There seems to be no submodule for > it anyway? > On Jan 19, 2014 10:40 PM, "Matthew N." wrote: > >> Thanks for clarifying. >> >> Myself, Jared Wein, and Paolo Amadini (Download Manager Owner) seem to be >> missing from the Toolkit peer list then. >> >> Thanks, >> Matthew >> >> On 1/19/14, 8:47 PM, Dave Townsend wrote: >> >>> Everyone who is a preferred reviewer should be a peer, if they aren't it's >>> likely because I forgot to update the appropriate lists. Who do you see >>> who >>> is absent from the peer list? >>> >>> >>> On Sat, Jan 18, 2014 at 11:51 AM, Matthew N. wrote: >>> >>> Hello, What does it mean to be a "Preferred Reviewer" (previously called a "peer") in a Toolkit sub-module[1] and not be on the list of Toolkit Peers[2]? The Toolkit Code Review page[3] doesn't seem to cover this case. Specifically: 1) Can a "Preferred Reviewer" review code in the related submodule without oversight from the sub-module owner? 2) Is a sub-module "Preferred Reviewer" considered a "Toolkit reviewer" for the purposes of [3]? Thanks, MattN [1] https://wiki.mozilla.org/Toolkit/Submodules [2] https://wiki.mozilla.org/Modules/Toolkit [3] https://wiki.mozilla.org/Toolkit/Code_Review ___ 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 >> > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform signature.asc Description: Message signed with OpenPGP using GPGMail ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Toolkit sub-module Preferred Reviewers who are not Toolkit Peers
I refactorted and debugged most of the findbar code. Mike seems to the de facto owner, so I think it makes sense for me to do reviews. I doubt anybody else knows much about the code. There seems to be no submodule for it anyway? On Jan 19, 2014 10:40 PM, "Matthew N." wrote: > Thanks for clarifying. > > Myself, Jared Wein, and Paolo Amadini (Download Manager Owner) seem to be > missing from the Toolkit peer list then. > > Thanks, > Matthew > > On 1/19/14, 8:47 PM, Dave Townsend wrote: > >> Everyone who is a preferred reviewer should be a peer, if they aren't it's >> likely because I forgot to update the appropriate lists. Who do you see >> who >> is absent from the peer list? >> >> >> On Sat, Jan 18, 2014 at 11:51 AM, Matthew N. wrote: >> >> Hello, >>> >>> What does it mean to be a "Preferred Reviewer" (previously called a >>> "peer") in a Toolkit sub-module[1] and not be on the list of Toolkit >>> Peers[2]? The Toolkit Code Review page[3] doesn't seem to cover this >>> case. >>> >>> Specifically: >>> 1) Can a "Preferred Reviewer" review code in the related submodule >>> without >>> oversight from the sub-module owner? >>> 2) Is a sub-module "Preferred Reviewer" considered a "Toolkit reviewer" >>> for the purposes of [3]? >>> >>> Thanks, >>> MattN >>> >>> [1] https://wiki.mozilla.org/Toolkit/Submodules >>> [2] https://wiki.mozilla.org/Modules/Toolkit >>> [3] https://wiki.mozilla.org/Toolkit/Code_Review >>> ___ >>> 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 > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Toolkit sub-module Preferred Reviewers who are not Toolkit Peers
On Sat, Jan 18, 2014 at 2:03 PM, Ms2ger wrote: > On 01/18/2014 08:51 PM, Matthew N. wrote: > >> Hello, >> >> What does it mean to be a "Preferred Reviewer" (previously called a >> "peer") in a Toolkit sub-module[1] and not be on the list of Toolkit >> Peers[2]? The Toolkit Code Review page[3] doesn't seem to cover this case. >> >> Specifically: >> 1) Can a "Preferred Reviewer" review code in the related submodule >> without oversight from the sub-module owner? >> 2) Is a sub-module "Preferred Reviewer" considered a "Toolkit reviewer" >> for the purposes of [3]? >> > > In general, all reviews should be done by peers, so people who are not > peers should not be listed as preferred reviewers. > > HTH > Ms2ger > > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > Historically we have given great deference to module owners who choose to delegate reviews to people who are not listed as peers, especially of patches written by the owner and listed peers. There are many reasons to do this, including working to grow new reviewers, choosing someone who understands a particularly specialized piece of code (potentially better than the owner), or load-balancing review requests by assigning reviews that need less scrutiny to people who are familiar with but not experts on the code in question. I don't think it's at all correct to say that all reviews should be done by peers. - Kyle PS. Don't you do a fair number of reviews in content/ and dom/? :P ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Toolkit sub-module Preferred Reviewers who are not Toolkit Peers
Thanks for clarifying. Myself, Jared Wein, and Paolo Amadini (Download Manager Owner) seem to be missing from the Toolkit peer list then. Thanks, Matthew On 1/19/14, 8:47 PM, Dave Townsend wrote: Everyone who is a preferred reviewer should be a peer, if they aren't it's likely because I forgot to update the appropriate lists. Who do you see who is absent from the peer list? On Sat, Jan 18, 2014 at 11:51 AM, Matthew N. wrote: Hello, What does it mean to be a "Preferred Reviewer" (previously called a "peer") in a Toolkit sub-module[1] and not be on the list of Toolkit Peers[2]? The Toolkit Code Review page[3] doesn't seem to cover this case. Specifically: 1) Can a "Preferred Reviewer" review code in the related submodule without oversight from the sub-module owner? 2) Is a sub-module "Preferred Reviewer" considered a "Toolkit reviewer" for the purposes of [3]? Thanks, MattN [1] https://wiki.mozilla.org/Toolkit/Submodules [2] https://wiki.mozilla.org/Modules/Toolkit [3] https://wiki.mozilla.org/Toolkit/Code_Review ___ 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: Workaround for hg.mozilla.org timeouts with TBPL try results
On 19/01/2014 16:38, Ed Morley wrote: On 19 January 2014 16:35:11, Ed Morley wrote: In addition, this change will mean that try repository resets (done periodically to avoid problems with the way we abuse mercurial for try server) will no longer stop you accessing old job results - as long as you have the revision URL from the original push email. [1] [1] Subject to TBPL's usual data purge 30 days after job completion. This is awesome! Thank you for doing this. :-) ~ Gijs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Exact rooting is now enabled on desktop
On 1/18/14, 9:04 AM, Terrence Cole wrote: Great question! We have a tool called "GC zeal" in builds with --enable-gc-zeal and in all debug builds unconditionally. It adds a small runtime overhead, but gives us fine-grained control over when GC's happen and adds several verification modes for debugging specific problems. I was under the impression that nightlys had this enabled, but I am not seeing it there now. Are there (inexpensive) runtime sanity checks that could be enabled in all Nightly release builds? The Nightly channel already has extra checks enabled that make it inappropriate for benchmarking, like --enable-profiling and some ref counting checks that will MOZ_CRASH. chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Toolkit sub-module Preferred Reviewers who are not Toolkit Peers
Everyone who is a preferred reviewer should be a peer, if they aren't it's likely because I forgot to update the appropriate lists. Who do you see who is absent from the peer list? On Sat, Jan 18, 2014 at 11:51 AM, Matthew N. wrote: > Hello, > > What does it mean to be a "Preferred Reviewer" (previously called a > "peer") in a Toolkit sub-module[1] and not be on the list of Toolkit > Peers[2]? The Toolkit Code Review page[3] doesn't seem to cover this case. > > Specifically: > 1) Can a "Preferred Reviewer" review code in the related submodule without > oversight from the sub-module owner? > 2) Is a sub-module "Preferred Reviewer" considered a "Toolkit reviewer" > for the purposes of [3]? > > Thanks, > MattN > > [1] https://wiki.mozilla.org/Toolkit/Submodules > [2] https://wiki.mozilla.org/Modules/Toolkit > [3] https://wiki.mozilla.org/Toolkit/Code_Review > ___ > 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: Workaround for hg.mozilla.org timeouts with TBPL try results
On 19 January 2014 16:35:11, Ed Morley wrote: In addition, this change will mean that try repository resets (done periodically to avoid problems with the way we abuse mercurial for try server) will no longer stop you accessing old job results - as long as you have the revision URL from the original push email. [1] [1] Subject to TBPL's usual data purge 30 days after job completion. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Workaround for hg.mozilla.org timeouts with TBPL try results
TBPL try pushes have recently been failing to load, due to problems with the try pushlog on hg.mozilla.org (bug 959769). In the last few days I have landed a workaround in TBPL (bug 721152) that means you can continue to see your job results for a single push, even if the hg.mozilla.org pushlog fails to load (fake pushlog values are displayed; but you can at least see the job results. To make use of this workaround, you must be using the single push URL present in the "thank you for your try push" email, of form: tbpl.mozilla.org/?tree=Try&rev=YOUR_PUSH In addition, this change will mean that try repository resets (done periodically to avoid problems with the way we abuse mercurial for try server) will no longer stop you accessing old job results - as long as you have the revision URL from the original push email. [1] The TBPL try overview page (showing all pushes, since no revision specified) will still be susceptible to hg.mozilla.org timeouts (sadly unavoidable; though the WIP treeherder architecture will mitigate this) - if this is causing problems for you, please ping the infra bug, bug 959769. Many thanks, Ed ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
