The last bullet for me is the killer feature. I recently hit an issue where I made some fairly big change to an API and updated all the consumers that I was aware and even ran a try push for the "happy" set. Unfortunately this burnt the tree.
I see this situation as a bigger waste of resources (sheriffs time, infrastructure time) than people not compiling their code and pushing to a tree. Obviously there is an issue that annotating the tree will only give you the "happy" set but that is much better than what we have now and would hopefully remove the need for people to workout what they need as try syntax, it would be done for them. David On 9 December 2014 at 18:46, 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
