Reorganizing Build Tools and Automation Components in Bugzilla

[Emma Humphries]

In bug https://bugzilla.mozilla.org/show_bug.cgi?id=1406536 we've discussed
a plan for reorganizing the Build Tools and Automation components in
Bugzilla.

The reasons for this are:

* build tools bugs are not the same as Firefox bugs and including them in
the Core and Firefox components distorts the numbers of open and untriaged
bugs
* build tools bugs get fixed quickly, we'd not be able to build firefox if
they are down
* untriaged and inactive build tools bugs are related to builds on
unsupported platforms

After some consideration, we've decided on this layout for a new product in
Bugzilla (thanks to gps for capturing this)


New Product: Firefox Build System and Automation

Components:

Build System <- Core :: Build Config, Firefox :: Build Config

- File bugs here for general Firefox build system issues. This includes
problems running `mach build`, `mach configure`, `mach package`, `mach
artifact`, and other mach commands related to building Firefox. This
component also tracks issues related to moz.build and make files.

Build System (Unsupported Platforms) (new component - to help us
better isolate bugs)

- Like the "Build System" component but for issues related to platforms
not officially supported by Mozilla's infrastructure (e.g. FreeBSD, NetBSD,
non-MacOS Darwin, etc).

Automation Task Configuration <- TaskCluster :: Task Configuration

- Tracks changes to how Firefox continuous integration (CI) tasks run.
This includes build and testing related tasks. If you want to request a
change to how some part of Firefox automation runs, this is a good place to
file a bug. (Automation could mean many things, whereas task evokes
taskcluster)

Mach Core <- Core :: Mach

- Tracking bugs and feature requests for mach: a generic CLI dispatching
tool. *Issues with specific `mach` commands used to develop Firefox should
be reported elsewhere. e.g. issues with `mach build` should be filed in the
"Build System" component.

System Bootstrap and Configuration (new component)

- Tracks issues related to the various tools that attempt to bootstrap
and configure a system to optimally build and develop Firefox. This
includes the standalone "mozboot" bootstrap.py script, `mach bootstrap`,
`mach mercurial-setup`, and `mach doctor`.

Source Code Analysis <- Testing :: Lint

- For issues related to linting tools (e.g. flake8, eslint), static
analysis tools (e.g. clang-analyze), and code formatting tools (e.g.
clang-format). Feature requests for better ways to analyze or reformat
source code can also be filed here.

Generated Documentation (new component)

- For issues related to documentation generated from in-repository
content. This covers the Sphinx documentation (`mach doc` and
https://firefox-source-docs.mozilla.org/)

IDE, Editor, Debugger, and Miscellaneous Tool Integration (new
component - I think)

- For issues related to integrating Firefox development into other
tools. e.g. Visual Studio and Eclipse integration. gdb and rr integration.
Issues developing with the Emacs operating system.

If you have comments on this reorganization, please respond to this by next
Thursday, the 16th. We'll schedule the move for after Thanksgiving.

-- Emma

[Dustin Mitchell]

> Generated Documentation (new component)

Who will be responsible for this component?

Dustin

[Sylvestre Ledru]

On 11/11/2017 00:41, Emma Humphries wrote:
> In bug https://bugzilla.mozilla.org/show_bug.cgi?id=1406536 we've
> discussed a plan for reorganizing the Build Tools and Automation
> components in Bugzilla.
>

[...]

> Source Code Analysis <- Testing :: Lint
>

> * For issues related to linting tools (e.g. flake8, eslint), static

> analysis tools (e.g. clang-analyze), and code formatting tools
> (e.g. clang-format). Feature requests for better ways to analyze
> or reformat source code can also be filed here.
>
>

We have been also using core::Rewriting and Analysis for this.

What will happen to this?

Thanks
Sylvestre

[Steve Fink]

Yeah, this is a questionable one, because there's a range of things that
could be described as static analysis and code formatting. It would seem
kind of odd to have clang-format in the same component as the rooting
hazard analysis, for example.

You might be able to make a distinction between syntax and semantics?
clang-format is syntax, clang-analyzer and the rooting analysis are
semantics. Most linting is syntax. If you go this route, you could just
drop static analysis from this list.

But I don't know what things that would move around; perhaps a better
distinction is between the implementations of the analyses vs their
integration into the build system or continuous integration.

[Andrew Halberstadt]

Why don't we keep the component name as 'Lint' for now (so it's just moving
products). We can file a follow-up to figure out what to do (if anything)
with Core :: Rewriting and Analysis.

On Sun, Nov 12, 2017 at 7:30 PM Steve Fink <sf...@mozilla.com> wrote:

> On 11/12/17 1:14 PM, Sylvestre Ledru wrote:
>
>
>
> On 11/11/2017 00:41, Emma Humphries wrote:
>
> In bug https://bugzilla.mozilla.org/show_bug.cgi?id=1406536 we've
> discussed a plan for reorganizing the Build Tools and Automation components
> in Bugzilla.
>
> [...]
>
> Source Code Analysis <- Testing :: Lint
>

> - For issues related to linting tools (e.g. flake8, eslint), static

[Mark Banner]

On 10/11/2017 23:41, Emma Humphries wrote:

> Source Code Analysis <- Testing :: Lint
>

> * For issues related to linting tools (e.g. flake8, eslint), static

> analysis tools (e.g. clang-analyze), and code formatting tools
> (e.g. clang-format). Feature requests for better ways to analyze
> or reformat source code can also be filed here.
>

Up until now, the Testing::Lint component has included items relating to
improving our own ESLint rules, and bugs for covering more directories
for ESLint, or enabling more rules.

Currently I'm starting to consider if it would be better to have an
additional component under Toolkit for those kinds of issues, and leave
the new Source Code Analysis component with issues relating to the
ESLint harness as part of Lint itself.

The main reasons I'm thinking about this are:

- The ESLint rules and what they cover relate to the Firefox code,
rather than actual building/automation. This has been feeling like
there's different sets of concerned people/triagers.
- There's better visibility for contributors to the Firefox code if bugs
relating to deploying the ESLint rules are in one of the Toolkit or
Firefox products.

The current component feels overloaded with two different categories,
and I think we should separate it out.

Mark.

[Emma Humphries]

Thanks to everyone who responded to this.

I've updated https://public.etherpad-mozilla.org/p/build-bug-components
with the suggestions and will ask Dylan to schedule the move.

Each of the new components in the product will need triage owners, so
please update the etherpad with your nominations for that role.

-- Emma

On Mon, Nov 13, 2017 at 11:46 PM, Mark Banner <mba...@mozilla.com> wrote:

> On 10/11/2017 23:41, Emma Humphries wrote:
>
> Source Code Analysis <- Testing :: Lint
>

> - For issues related to linting tools (e.g. flake8, eslint), static