Reworking RelEng bugzilla components

tl;dr: RelEng has renamed + re-scoped our Bugzilla components, added some new components, and moved them all to a new top-level “Release Engineering” product. This should make it easier for people to file bugs in RelEng, improve triaging so bugs dont get lost, and help us scale. We think this is a big improvement, and hope you like it.

The scope, and the nature, of Release Engineering has evolved significantly over the last 6 years. As our responsibilities grow, the group grows, and as we re-scope who works on what, our old components simply weren’t working well for us anymore. It was getting tricky to keep track of new incoming new bugs, it was unclear (and inconsistent) on where new bugs should be filed, existing bugs were getting lost in the noise and triage of all this was becoming unwieldy. We already did one big change of our components at the start of the year (2013), which helped a bunch, but which we felt could be improved further. Today, after lots of planning, these changes went live, with thanks to glob for his behind-the-scenes-bugzilla-magic.

These new components may not be perfect (!), but we believe this is a big improvement over what we had earlier this year, and which is, in turn an improvement over what we had before that!

Of course, renaming and creating new components doesn’t actually *fix* bugs. But, this change should make it easier for people to file bugs in the right component, easier for RelEng to triage, and harder for bugs to fall through the cracks.

This reshuffle is already helping cleanup our backlog – we’ve already found bugs that were DUPs, as well as fixed-long-ago-yet-left-open bugs. Please do be patient with us while we triage our way through all our bugs, and if we update a long-sleeping bug of yours asking for more info, please do bear with us while we figure all these out.

ps: You can see more details in bug#898244, but the summary is:

0) Saved searches that relied on the ID of the renamed components should be ok, but saved searches that relied on matching the component name will need to be updated.

1) The new name and scope for each component is as follows:

Release Engineering: Buildduty:
This component tracks the routine care and feeding of RelEng systems (machine management), reconfigs of masters, and any tree closures or
downtimes. This includes physical machines in any of Mozilla’s colos, as well as instances in AWS.

Release Engineering: Loan Requests:
This component tracks all requests from developers for a loan of a production machines.

Release Engineering: General Automation:
This component tracks

  • Modifying or removing existing builds, tests and other jobs
  • Adding support for new types of jobs, builds or tests (e.g. opt, pgo,
    debug, ASAN or code coverage builds; b2g device builds, new test suites;
    special builds like spidermonkey or valgrind)
  • Scheduler changes: what jobs get run and when

Release Engineering: Release Automation:
This component tracks bugs related to the Release Automation including, but not limited to buildbot code.

Release Engineering: Releases:
This component tracks bugs related to specific releases, or updates to those releases.

Release Engineering: Tools:
This component tracks large scale tools used to interact with RelEng systems. Some examples include (but are not limited to):

  • vcs2vcs, balrog, tryserver/trychooser, cloud-tools, buildapi,
    self-serve, hg/git mapper, integration-with-s3, tools-for-sheriffs,
    autoland, kittenherder…
  • alerts for colo outages, long-running-jobs,
  • reports for wait-times, try-server-top-users, cost reporting, slave health, …

Release Engineering: Platform Support:
This component tracks requests for supporting builds/tests on a new operating system. (Examples include: android x86, win 8.1, osx10.9). This component also tracks requests for toolchain changes (new versions of compilers, python, hg, git, puppet, GPO, etc.)

Release Engineering: Repos and Hooks:
This component handles creating/deleting Mercurial and Git repos on and respectively, any mirroring between those systems, as well as any hooks on those repos. Note: This used to be the unowned component, which has significant production impact, and overlapped with work we do for new repo requests, so made sense to include here.

Release Engineering: Other:
This component is used for goals, tracking bugs, and any general RelEng work that spans across different RelEng components. Anything that doesn’t fit in any other component goes here.


One thought on “Reworking RelEng bugzilla components”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.