633c996e87fbbbb95d05fec042ea224e12aaf7c9: Bug 1132771 - Add ability to audit file metadata draft
Gregory Szorc <gps@mozilla.com> - Tue, 24 Feb 2015 16:25:36 -0800 - rev 245803
Push 799 by gszorc@mozilla.com at Wed, 25 Feb 2015 01:17:13 +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.
50a281f3355faec9573b299668627377f686fd49: Bug 1132771 - Define some reviewers draft
Gregory Szorc <gps@mozilla.com> - Fri, 20 Feb 2015 20:50:01 -0800 - rev 245802
Push 799 by gszorc@mozilla.com at Wed, 25 Feb 2015 01:17:13 +0000
Bug 1132771 - Define some reviewers
8575b7056c9670d82186b754a3f5aafb30de401f: Bug 1132771 - Support for defining code reviewer metadata draft
Gregory Szorc <gps@mozilla.com> - Fri, 20 Feb 2015 20:44:03 -0800 - rev 245801
Push 799 by gszorc@mozilla.com at Wed, 25 Feb 2015 01:17:13 +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.
22f27f69f7d2b2c9a143dbb738bc24f668fe3c0b: Bug 1132771 - Implement file-info mach command draft
Gregory Szorc <gps@mozilla.com> - Tue, 24 Feb 2015 15:56:25 -0800 - rev 245800
Push 799 by gszorc@mozilla.com at Wed, 25 Feb 2015 01:17:13 +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.
ac251d7c3ada031f21159d989f0e1b9b12819d47: Bug 1132771 - Define some bug components draft
Gregory Szorc <gps@mozilla.com> - Tue, 24 Feb 2015 15:37:03 -0800 - rev 245799
Push 799 by gszorc@mozilla.com at Wed, 25 Feb 2015 01:17:13 +0000
Bug 1132771 - Define some bug components This patch defines bug components for code that I have historically touched.
9a453e8066088a41062ec707acbf82460af0b76e: 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 245798
Push 799 by gszorc@mozilla.com at Wed, 25 Feb 2015 01:17:13 +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.
e1322110f312e455f04ac1967038dfa2b9af4880: Bug 1132771 - Implement strongly typed named tuples draft
Gregory Szorc <gps@mozilla.com> - Tue, 24 Feb 2015 15:34:14 -0800 - rev 245797
Push 799 by gszorc@mozilla.com at Wed, 25 Feb 2015 01:17:13 +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.
c23d7e1908067bc007c5839c1cbfcd5de2cc2405: Bug 1132771 - Convert Sphinx to sub-contexts draft
Gregory Szorc <gps@mozilla.com> - Tue, 24 Feb 2015 15:33:56 -0800 - rev 245796
Push 799 by gszorc@mozilla.com at Wed, 25 Feb 2015 01:17:13 +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.
1b049e6ab8723cb3d1ef0e571d6d1ffc8cc7c2f4: 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 245795
Push 799 by gszorc@mozilla.com at Wed, 25 Feb 2015 01:17:13 +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.
091c31bdf2fc22f1b2aba2389214b98da4ca203f: 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 245794
Push 799 by gszorc@mozilla.com at Wed, 25 Feb 2015 01:17:13 +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.
438fef731cc540b3d5d8a9f59238d09c023ac5da: Bug 1132771 - Support reading relevant moz.build files draft
Gregory Szorc <gps@mozilla.com> - Tue, 24 Feb 2015 17:13:03 -0800 - rev 245793
Push 799 by gszorc@mozilla.com at Wed, 25 Feb 2015 01:17:13 +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. Since variable exporting doesn't work reliably in this new traversal mode, variable exporting no-ops when this mode is activated.
b7614152a103a1828b658b13287ca72438f7cf54: Bug 1132771 - Pass special types down to sandboxes via metadata draft
Gregory Szorc <gps@mozilla.com> - Tue, 24 Feb 2015 16:55:23 -0800 - rev 245792
Push 799 by gszorc@mozilla.com at Wed, 25 Feb 2015 01:17:13 +0000
Bug 1132771 - Pass special types down to sandboxes via metadata Currently, MozSandbox assumes that the FUNCTIONS, SPECIAL_VARIABLES, and SUBCONTEXTS data structures are the instances that should be associated with the sandbox. As we introduce new moz.build processing modes that wish to change processing behavior, it is necessary for them to have control over these special symbols. This patch moves the declaration of these types to the special metadata dictionary which is inherited during recursion. The "read_topsrcdir" API now explicitly passes the initial metadata into "read_mozbuild".
6d03e7ef3feed3ae52ee3bc6e69503434f93a8a7: 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 245791
Push 799 by gszorc@mozilla.com at Wed, 25 Feb 2015 01:17:13 +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.
1deb8114e4ee3859b513681072e0b5b30cff7b15: 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 245790
Push 799 by gszorc@mozilla.com at Wed, 25 Feb 2015 01:17:13 +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.
b8bb3765cd3829ebec599725fc7f2c9c2ab82daf: Bug 1134072 - Support for sub-contexts; r=glandium draft
Gregory Szorc <gps@mozilla.com> - Tue, 24 Feb 2015 13:05:59 -0800 - rev 245789
Push 799 by gszorc@mozilla.com at Wed, 25 Feb 2015 01:17:13 +0000
Bug 1134072 - Support for sub-contexts; r=glandium As content in moz.build files has grown, it has become clear that storing everything in one global namespace (the "context") per moz.build file will not scale. This approach (which is carried over from Makefile.in patterns) limits our ability to do things like declare multiple instances of things (like libraries) per file. A few months ago, templates were introduced to moz.build files. These started the process of introducing separate contexts / containers in each moz.build file. But it stopped short of actually emitting multiple contexts per container. Instead, results were merged with the main context. This patch takes sub-contexts to the next level. Introduced is the "SubContext" class. It is a Context derived from another context. SubContexts are special in that they are context managers. With the context manager is entered, the SubContext becomes the main context associated with the executing sandbox, temporarily masking the existence of the main context. This means that UPPERCASE variable accesses and writes will be handled by the active SubContext. This allows SubContext instances to define different sets of variables. When a SubContext is spawned, it is attached to the sandbox executing it. The moz.build reader will now emit not only the main context, but also every SubContext that was derived from it. To aid with the creation and declaration of sub-contexts, we introduce the SUBCONTEXTS variable. This variable holds a list of classes that define sub-contexts. Sub-contexts behave a lot like templates. Their class names becomes the symbol name in the sandbox.
eb1b74f093833f79283819e4edbe894d97d05eeb: Passwords category. draft
Chenxia Liu <liuche@mozilla.com> - Tue, 24 Feb 2015 16:52:52 -0800 - rev 245788
Push 798 by cliu@mozilla.com at Wed, 25 Feb 2015 00:52:58 +0000
Passwords category.
33d7f9574d5154ba204279962fa0298ddd81aad6: Bug 1136450 - WebIDE packaging check did not function correctly. r=ochameau draft
J. Ryan Stinnett <jryans@gmail.com> - Tue, 24 Feb 2015 18:39:08 -0600 - rev 245787
Push 797 by jryans@gmail.com at Wed, 25 Feb 2015 00:39:19 +0000
Bug 1136450 - WebIDE packaging check did not function correctly. r=ochameau
b6554e486c6d443ba3f219cf6dfc068007d4e14a: Merge m-c to fx-team a=merge CLOSED TREE
Wes Kocher <wkocher@mozilla.com> - Tue, 24 Feb 2015 15:44:59 -0800 - rev 245786
Push 797 by jryans@gmail.com at Wed, 25 Feb 2015 00:39:19 +0000
Merge m-c to fx-team a=merge CLOSED TREE
0a8b3b67715ac0f58470431ebf0052a265055e40: Merge fx-team to m-c a=merge
Wes Kocher <wkocher@mozilla.com> - Tue, 24 Feb 2015 15:41:09 -0800 - rev 245785
Push 797 by jryans@gmail.com at Wed, 25 Feb 2015 00:39:19 +0000
Merge fx-team to m-c a=merge
204c5ec572eb85bf355b043c17026589fef52e43: Merge b2g-inbound to m-c a=merge
Wes Kocher <wkocher@mozilla.com> - Tue, 24 Feb 2015 15:36:56 -0800 - rev 245784
Push 797 by jryans@gmail.com at Wed, 25 Feb 2015 00:39:19 +0000
Merge b2g-inbound to m-c a=merge
(0) -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 +300000 tip