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
