I'm starting to work on this implementation. https://reviewboard.mozilla.org/r/3817/
Feel free to comment on the diffs. https://reviewboard.mozilla.org/r/3935/diff/#0 is where it starts to get interesting. On Tue, Dec 9, 2014 at 10:46 AM, Gregory Szorc <g...@mozilla.com> wrote: > In Portland, there were a number of discussions around ideas and features > that could be easier implemented if only we had better metadata and > annotations for source files. For example: > > * Suggested reviewers for a patch > * Determine the Bugzilla component for a failing test > * Determine the Bugzilla component for a changed file so a bug can be > filed automatically > * Building a subscription service for watching code and reviews > * Defining what static analysis should run on a given source file > * Mapping changed files to impacted automation jobs (useful for minimizing > automation that runs) > > There is pretty much universal consensus that as much metadata as possible > should live in the tree, next to the things being annotated. This is in > contrast to how current systems like Bugzilla's suggested reviewers feature > operate, which is to establish a separate service/data store, essentially > fragmenting the source of truth and introducing one-off change processes. > > I discussed options with Mike Hommey and we believe that moz.build files > are the appropriate default location for this metadata. We considered > alternatives such as moz.build-like Python sandboxes under a different > filename and standalone JSON or YAML files. We like moz.build because it is > a fully customizable Python environment that already exists and therefore > doesn't require much effort to stand up and doesn't fragment source of > truth. > > This should not be a surprise: capturing non-build metadata in moz.build > files was always an eventual goal. There is already precedence for this in > defining the Sphinx documentation [1]. We just haven't had a good reason or > time to add more things. Until now. > > In the weeks and months ahead, expect to start seeing work to integrate > extra metadata into moz.build files. This may require refactoring some > moz.build files. We'll need to support a world where moz.build files can be > evaluated before configure is executed (so any tool with a copy of the > source and the Python package for reading moz.build files can extract > metadata in milliseconds). > > This work should enable all kinds of awesome tooling and developer > productivity wins. > > If anyone has any other crazy ideas for what metadata to capture in > moz.build files to help improve processes, I'm definitely interested in > hearing them! > > [1] https://ci.mozilla.org/job/mozilla-central-docs/Tree_ > Documentation/index.html#adding-documentation > _______________________________________________ > 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
