This spreadsheet contains a list of files and their most frequently associated bug component from commits landed since 2014.
https://docs.google.com/spreadsheets/d/1cz2-UC_LN_OFM2q67rKi6Mo-2TpdN8fTiH8LstZJ4PM/edit?usp=sharing If a file is missing, it likely hasn't been modified in the past ~14 months. Methodology: 1) hg log -r 2bf05c015b49:: -T '{join(bugs, " ")}\t{join(files, " ")}\n' (requires the mozext extension to provide {bugs}) 2) Drop commits modifying b2g/config/gaia.json (because the bug parser extracts the #123 syntax referencing GitHub issues) 3) Associate the first bug number with all files in the entry (this should be the "primary" bug associated with the commit) 4) Query Bugzilla for the bug component for every seen bug (sorry for traffic, glob) 5) Count occurrences of each component for each file 6) Take the component with the max bugs associated with it Let me know if you have any further questions or want a variation of the report. On Tue, Mar 3, 2015 at 4:56 PM, Andrew McCreight <amccrei...@mozilla.com> wrote: > Is there any kind of existing code around that would look at the bugs for > the commits for the files in a directory and create some kind of count of > the components they were filed in? dom/ has something like 90 > subdirectories, and it would be nice to be able to quickly get some kind of > census like that to guide writing BUG_COMPONENT thing. > > Andrew > > On Tue, Mar 3, 2015 at 10:16 AM, Gregory Szorc <g...@mozilla.com> wrote: > > > Support for the previously announced [1] intention to use moz.build to > > define metadata for files has now landed on mozilla-central with the > > landing of bug 1132771 [2]. > > > > This is important to you because there are plans to leverage this > metadata > > to make it easier to get stuff done. Some potential uses include: > > > > * automatically filing bugs against the proper component > > * automatically selecting reviewers for a patch > > * intelligently scheduling automation jobs based on what changed > > > > *But we can't do any of these things unless there is data to drive it.* > > That's where you come in. > > > > I would kindly request that you take a few minutes to help define which > > files in mozilla-central map to which Bugzilla components. The process > for > > doing this is relatively simple: > > > > 1) Read the docs on how file metadata works [3] > > 2) Write and land a patch (see [4] for an example patch) > > > > The newly-landed `mach file-info` command can be used to help you query > > metadata on files. Run `mach help file-info` for usage. > > > > If you need help, ask in #build. > > > > If you don't like how things work or if you have a suggestion for > > improvement, file a new bug depending on bug 1132771 and we'll go from > > there. You may be interested in bugs already on file, which include > support > > for defining code reviewers (bug 1137042) and the ability to audit > metadata > > for correctness (bug 1137043). > > > > Adding or changing "Files" entries in moz.build files does not require > > build peer review. > > > > [1] > > > > > https://groups.google.com/d/msg/mozilla.dev.platform/iXr70VgapWk/GkTCcKRjNi8J > > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1132771 > > [3] > > > > > https://ci.mozilla.org/job/mozilla-central-docs/Tree_Documentation/build/buildsystem/files-metadata.html > > [4] https://hg.mozilla.org/integration/mozilla-inbound/rev/4cc39c54099d > > _______________________________________________ > > 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 > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
