Re: Reorganizing Build Tools and Automation Components in Bugzilla

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 <[email protected]> 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
>    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.
>