Reorganizing Build Tools and Automation Components in Bugzilla

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Reorganizing Build Tools and Automation Components in Bugzilla

Dustin Mitchell
> Generated Documentation       (new component)

Who will be responsible for this component?

Dustin
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Reorganizing Build Tools and Automation Components in Bugzilla

Sylvestre Ledru-2
In reply to this post by Emma Humphries


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

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Reorganizing Build Tools and Automation Components in Bugzilla

Steve Fink-4
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
>>     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?

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.


_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Reorganizing Build Tools and Automation Components in Bugzilla

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 <[hidden email]> 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
>    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?
>
> 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.
>
>
>
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Reorganizing Build Tools and Automation Components in Bugzilla

Mark Banner-4
In reply to this post by Emma Humphries
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.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Reorganizing Build Tools and Automation Components in Bugzilla

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 <[hidden email]> 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.
>
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning