4aad4f99b867973adbcc78b346e8e13fcf081a9c: Bug 1130834 - Explictly cancel ongoing download notifications instead of trying to update them to be non-ongoing. r=wesj
Margaret Leibovic <margaret.leibovic@gmail.com> - Sun, 22 Feb 2015 17:18:39 -0800 - rev 245753
Push 797 by jryans@gmail.com at Wed, 25 Feb 2015 00:39:19 +0000
Bug 1130834 - Explictly cancel ongoing download notifications instead of trying to update them to be non-ongoing. r=wesj
50f5c97e537141de3d5e369d35684ffa2cfc251e: Bug 1121681 - Add "Passwords" entry point in menu. r=mhaigh draft
Chenxia Liu <liuche@mozilla.com> - Tue, 24 Feb 2015 16:29:38 -0800 - rev 245752
Push 796 by cliu@mozilla.com at Wed, 25 Feb 2015 00:30:18 +0000
Bug 1121681 - Add "Passwords" entry point in menu. r=mhaigh
1fc4d116123b942fb4a63b5d1be53660e35c8437: Bug 1132771 - Add ability to audit file metadata draft
Gregory Szorc <gps@mozilla.com> - Tue, 24 Feb 2015 16:25:36 -0800 - rev 245751
Push 795 by gszorc@mozilla.com at Wed, 25 Feb 2015 00:26:50 +0000
Bug 1132771 - Add ability to audit file metadata Metadata stored in Files is only useful if it is accurate. We want a process to help ensure the data is proper. This patch introduces |mach file-info --audit|. It will read every moz.build file and look for invalid entries. We currently query Bugzilla for product and user info. If referenced entitites don't exist, we emit a warning. We can't hook this feature up to existing tests because it requires network access. Instead, we'll need to deploy a separate system for periodically running this audit and reporting on results. Something similar to the Jenkins job that's doing Sphinx documentation generation should suffice.
c015fb838ecbfe0bf7fd4def92acf272fe8aa5b1: Bug 1132771 - Define some reviewers draft
Gregory Szorc <gps@mozilla.com> - Fri, 20 Feb 2015 20:50:01 -0800 - rev 245750
Push 795 by gszorc@mozilla.com at Wed, 25 Feb 2015 00:26:50 +0000
Bug 1132771 - Define some reviewers
3fdafd1c15f0ec2b79f6f7f374166225d0789c2f: Bug 1132771 - Support for defining code reviewer metadata draft
Gregory Szorc <gps@mozilla.com> - Fri, 20 Feb 2015 20:44:03 -0800 - rev 245749
Push 795 by gszorc@mozilla.com at Wed, 25 Feb 2015 00:26:50 +0000
Bug 1132771 - Support for defining code reviewer metadata It is now possible to define code reviewers on Files sub-contexts. I thought about various use cases for defining code reviewers and I believe the extra complexity for removing reviewers and adjusting the weight of reviewers is warranted. There are plenty of edge cases in our tree where certain individuals want domain over specific files or directories. Or, we may have a large group with review powers over a large umbrella of directories with certain parts gravitating towards specific individuals. I believe the implementation should cater to the needs of most. If we need additional edge cases, we can always implement them later.
9cabc294c3d221a173d9e8d4151306198cba908d: Bug 1132771 - Implement file-info mach command draft
Gregory Szorc <gps@mozilla.com> - Tue, 24 Feb 2015 15:56:25 -0800 - rev 245748
Push 795 by gszorc@mozilla.com at Wed, 25 Feb 2015 00:26:50 +0000
Bug 1132771 - Implement file-info mach command Now that we have a mechanism for defining file-based metadata, let's add a mach command to interface with it. Currently, we limit ourselves to simple Bugzilla data dumping. Features will be added over time.
1faaf5ff358080740129ca61e644272e680d9858: Bug 1132771 - Define some bug components draft
Gregory Szorc <gps@mozilla.com> - Tue, 24 Feb 2015 15:37:03 -0800 - rev 245747
Push 795 by gszorc@mozilla.com at Wed, 25 Feb 2015 00:26:50 +0000
Bug 1132771 - Define some bug components This patch defines bug components for code that I have historically touched.
6d143a910f5ecf67d9dec302087aa20777ec6772: Bug 1132771 - Add Files to moz.build with ability to define Bugzilla component draft
Gregory Szorc <gps@mozilla.com> - Tue, 24 Feb 2015 15:16:54 -0800 - rev 245746
Push 795 by gszorc@mozilla.com at Wed, 25 Feb 2015 00:26:50 +0000
Bug 1132771 - Add Files to moz.build with ability to define Bugzilla component The Files sub-context allows us to attach metadata to files based on pattern matching rules. Patterns are matched against files in a last-write-wins fashion. The sub-context defines the BUG_COMPONENT variable, which is a 2-tuple (actually a named tuple) defining the Bugzilla product and component for files. There are no consumers yet. But an eventual use case will be to suggest a bug component for a patch/commit. Another will be to automatically suggest a bug component for a failing test.
0abecb688ea33fb34f27d34442e19bf93bad99c7: Bug 1132771 - Implement strongly typed named tuples draft
Gregory Szorc <gps@mozilla.com> - Tue, 24 Feb 2015 15:34:14 -0800 - rev 245745
Push 795 by gszorc@mozilla.com at Wed, 25 Feb 2015 00:26:50 +0000
Bug 1132771 - Implement strongly typed named tuples An upcoming patch introduces a use case for a strongly typed named tuple. So, we introduce a generic factor function that can produce these types.
9cb3d842d80a4ef0f022b3ffb36ce1a6f25cea6c: Bug 1132771 - Convert Sphinx to sub-contexts draft
Gregory Szorc <gps@mozilla.com> - Tue, 24 Feb 2015 15:33:56 -0800 - rev 245744
Push 795 by gszorc@mozilla.com at Wed, 25 Feb 2015 00:26:50 +0000
Bug 1132771 - Convert Sphinx to sub-contexts Now that we have support for defining sub-contexts and for reading all moz.build files without a build config, convert Sphinx to be sub-contexts. This gets rid of the gross AST-based moz.build reading hacks that were previously introduced in order to read Sphinx variables without having a full build system context. Good riddance. Since this is the first use of sub-contexts, we need to teach the emitter to not treat them like normal contexts. Since Sphinx data is handled by code under tools/docs, we just ignore them in the emitter. This is arguably not correct. But it is easier then teaching all downstream systems about sub-contexts.
4e49a5dbcd3e612ab66916857d1e5cf3bb58f5c0: Bug 1132771 - Support and test for reading without a config object draft
Gregory Szorc <gps@mozilla.com> - Thu, 19 Feb 2015 11:58:48 -0800 - rev 245743
Push 795 by gszorc@mozilla.com at Wed, 25 Feb 2015 00:26:50 +0000
Bug 1132771 - Support and test for reading without a config object We wish to utilize the Files metadata in moz.build files without having to create a build configuration (which requires running configure). This will enable tools to consume metadata by merely having a copy of the source code and nothing more. Declare an EmptyConfig object to be used for processing moz.build files in "no config" mode and write a test that ensures the tree can be read without a config. This test is necessary to ensure that tools relying on "no config" mode continue to work.
dab1a8bdb125e44e0103c8ee68e495a68e1d369c: Bug 1132771 - Add a test for reading all moz.build files in filesystem traversal mode draft
Gregory Szorc <gps@mozilla.com> - Wed, 18 Feb 2015 20:44:59 -0800 - rev 245742
Push 795 by gszorc@mozilla.com at Wed, 25 Feb 2015 00:26:50 +0000
Bug 1132771 - Add a test for reading all moz.build files in filesystem traversal mode moz.build files should execute in filesystem traversal mode. Add a test that verifies this is true. This test performs a brute force filesystem scan to find relevant moz.build files. This can be a little slow. That's unfortunate. But it's a price we need to pay in order to ensure metadata extraction mode continues to work.
deda19f28f5e82863604177fd2ec6a53d9f8ab87: Bug 1132771 - Optionally don't export variables when reading moz.build files draft
Gregory Szorc <gps@mozilla.com> - Thu, 12 Feb 2015 18:58:37 -0800 - rev 245741
Push 795 by gszorc@mozilla.com at Wed, 25 Feb 2015 00:26:50 +0000
Bug 1132771 - Optionally don't export variables when reading moz.build files Exporting the same variable twice in a stack of traversals results in an error. Since we don't need exported variables when in manual moz.build traversal mode, add an option to disable it and disable it in our manual traversal mode.
097cb6af15b54f89d9280147a289abf5eeba6154: Bug 1132771 - Support reading relevant moz.build files draft
Gregory Szorc <gps@mozilla.com> - Tue, 24 Feb 2015 12:36:54 -0800 - rev 245740
Push 795 by gszorc@mozilla.com at Wed, 25 Feb 2015 00:26:50 +0000
Bug 1132771 - Support reading relevant moz.build files Building on top of the API to retrieve relevant moz.build files for a given path, we introduce a moz.build reading API that reads all moz.build files relevant to a given set of paths. We plan to use this new API to read metadata from moz.build files relevant to a set of files. This patch changes the generator behavior of read_mozbuild to emit the main context before any processing occurs. This allows downstream consumers to manipulate state of the context before things like directory processing occurs. We utilize this capability in the new reading API to forcefully declare the directory traversal order for processed moz.build files, overriding DIRS and similar variables.
ad85cd50819d61d8a0c0a8eb3b88aa4ff2123031: Bug 1132771 - API to return moz.build files relevant for a set of paths draft
Gregory Szorc <gps@mozilla.com> - Tue, 24 Feb 2015 10:44:09 -0800 - rev 245739
Push 795 by gszorc@mozilla.com at Wed, 25 Feb 2015 00:26:50 +0000
Bug 1132771 - API to return moz.build files relevant for a set of paths We have an eventual goal to store file-level metadata in moz.build files and to have this metadata "cascade" down directory hierarchies. e.g. metadata in the root directory will apply to all children directories. A prerequisite for this feature is a way to query which moz.build files are relevant to a given file. In this patch, we implement an API that returns this information.
c97c977c92b97c9585011651b13a088f0cd4ed4f: Bug 1132771 - moz.build fixups to enable execution in no config mode draft
Gregory Szorc <gps@mozilla.com> - Thu, 19 Feb 2015 10:58:41 -0800 - rev 245738
Push 795 by gszorc@mozilla.com at Wed, 25 Feb 2015 00:26:50 +0000
Bug 1132771 - moz.build fixups to enable execution in no config mode Various moz.build files fail to execute when a build config is not present. Many of these are due to assuming certain CONFIG entries are present. This patch attempts to fix that and enable every moz.build to be read without a build config.
5448050404c59576081a8e16ebbe3725fe41836c: Bug 1056002 - Backout changeset c56275d516ec. r=mfinkle draft
Michael Comella <michael.l.comella@gmail.com> - Tue, 24 Feb 2015 16:12:32 -0800 - rev 245737
Push 794 by michael.l.comella@gmail.com at Wed, 25 Feb 2015 00:14:18 +0000
Bug 1056002 - Backout changeset c56275d516ec. r=mfinkle This change caused a lot of fullscreen issues (see the dependent bugs).
0a3ff6c99a9bf9850a2038b4dc4e74546bf7b1f3: Bug 1134192 - Prevent the options menu from opening in fullscreen mode. r=mfinkle
Michael Comella <michael.l.comella@gmail.com> - Mon, 23 Feb 2015 13:12:01 -0800 - rev 245736
Push 794 by michael.l.comella@gmail.com at Wed, 25 Feb 2015 00:14:18 +0000
Bug 1134192 - Prevent the options menu from opening in fullscreen mode. r=mfinkle
5eab6df483fb6d716e7816288742eac69bb25d3b: Bug 1134192 - Add ActivityUtils.isFullScreen. r=mfinkle
Michael Comella <michael.l.comella@gmail.com> - Mon, 23 Feb 2015 13:11:21 -0800 - rev 245735
Push 794 by michael.l.comella@gmail.com at Wed, 25 Feb 2015 00:14:18 +0000
Bug 1134192 - Add ActivityUtils.isFullScreen. r=mfinkle A more complete solution would rework our fullscreen support to ensure the flags are consistently used (e.g. reader mode just uses low_profile even though ActivityUtils.setFullScreen does both low profile and fullscreen).
9853847b7c79b9360f5d5870d7359e7c9e362f94: Bug 1134395 - mozbuild should pass in rootdir to manifestparser to properly calculate test relpaths, r=gps draft
Andrew Halberstadt <ahalberstadt@mozilla.com> - Wed, 18 Feb 2015 17:07:55 -0500 - rev 245734
Push 793 by ahalberstadt@mozilla.com at Tue, 24 Feb 2015 22:02:29 +0000
Bug 1134395 - mozbuild should pass in rootdir to manifestparser to properly calculate test relpaths, r=gps
(0) -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 +300000 tip