servo directory in-tree has no BUGZILLA_COMPONENTS information

RESOLVED FIXED

Status

()

enhancement
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: jmaher, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

I had asked about this ~6 months ago, now the tree is basically done being annotated and we have a job run per/push which generates a map of source files -> bugzilla_component.  Ideally that job will go orange when we find files that do not have a clear owner- ownership is important in open source so when there are issues or questions with code any contributor can raise a bug and get it to the right people.
:jryans- would you know who could help out here outlining bugzilla_components for source files in servo/* ?  I assume this will be a mapping to specific directories vs individual files.
Flags: needinfo?(jryans)
the contents of the servo/ directory are an overlay of the servo/servo github repo.
servo-vcs-sync is the automation which performs this task; configuration of moz.build files is outside of its scope, moving to core::general.

if you want to add a moz.build file to the servo directory you need to file a pull-request on github.com/servo/servo to get it added.  i'm not sure, but i suspect another option would be to update the root moz.build file.

as far as i'm aware servo issues are tracked mostly as github issues – however in places where there's interaction with gecko (eg. stylo) there are existing bugzilla components which deal with the related changes to gecko.
Component: Servo VCS Sync → General
Product: Developer Services → Core
The Stylo project has mostly used Bugzilla bugs for project tracking, even when only Servo side changes were made, so that project tracking isn't split across two trackers.

Here are some directories related to Stylo:

servo/components/style
servo/components/style_derive
servo/components/style_traits
servo/ports/geckolib
servo/tests/unit/style

Those could all potentially be mapped to Core :: CSS Parsing and Computation.

Like :glob said, I am not sure where you'd actually put the moz.build file to map them...  Maybe at the root of m-c is the right choice.

I am not sure if other projects have /servo directories that could map to bug components.  I believe projects like WebRender use other Rust crates outside of /servo.
Flags: needinfo?(jryans)
You can put the moz.build files in the servo repo itself and the Files() based metadata will "just work." There doesn't need to be a reference to the servo/ directory in a non-servo/ moz.build. Nothing in the servo repo/directory needs to consume the moz.build file.

We do this in version-control-tools: https://hg.mozilla.org/hgcustom/version-control-tools/file/tip/moz.build
I submitted a servo PR:
https://github.com/servo/servo/pull/19041

I assume this will get resolved in a reasonable amount of time
this landed today:
https://hg.mozilla.org/integration/autoland/rev/aeaa2a5a96f0fa916ba27d16be3de8a43f8ecf41
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.