(cross-posting to make sure this isnt missed - please reply in dev.planning.)
hi;
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.
Background:
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.
Thanks
John.
=====
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
hg.mozilla.org and git.mozilla.org respectively, any mirroring between
those systems, as well as any hooks on those repos. Note: This used to
be the unowned mozilla.org::HgCustomizations 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.
=====
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
