On Wed, Jun 8, 2016 at 12:04 PM, Gregory Szorc <g...@mozilla.com> wrote:
> Currently, there are 3 bug components related to the build system in > mozilla-central: > > Core :: Build Config > Firefox :: Build Config > Toolkit :: Build Config > > (The latter 2 aren't really used that often.) > > There are also a handful of other pieces of software that have strong > tie-ins to the build system. These include: > > * Core :: mach > * system bootstrap support > * Various mach commands like "mercurial-setup" and "doctor" > * mozharness, buildbot, and TaskCluster automation > > (The middle 2 don't really have bug components.) > > Maybe it's just me, but I've been finding Core :: Build Config a bit > overwhelming, especially when I want to e.g. find all bugs impacting a > sub-component of the build system, like artifact builds. I can't help but > feel important bugs are getting lost in the noise of the monolithic Core :: > Build Config component and others get lost in components nobody pays > attention to. > Please include Emma in your planning, as our bugmaster. She can help you design and maintain the tradeoff between more and fewer bug components is tricky to navigate: - Most bug filers already find our many bugzilla components overwhelming. In terms of the bug filing experience, fewer large components is clearly better. - Many individual engineers want many small components, because they want to be able to take responsibility for small subsystems without being overwhelmed with everything. - Small components also product "hot potato" syndrome where an important issue doesn't fit neatly into a box. I suspect we will be able to bridge this gap with the more effective bug triage that we're implementing now, and maybe some tagging systems. Since we've already committed to having bug triage for every component, it should be possible to have one or a few components but still have subcategories that subteams can use to prioritize work. I'm a little skeptical of having a completely separate build-config product. Would the scope of that include things (like Firefox for iOS) that don't use our build system at all? How can we scope this so that it's clearly about the gecko/Firefox/oxidation build system and not other independent Mozilla products? --BDS > > I'd like to float the idea of restructuring the build system's bug > components. How it would look, I'm not sure. I'll throw out the idea for a > top-level Bugzilla Product for all things related to the build system. e.g. > > Build System :: bootstrap and system configuration > Build System :: moz.build, configure, and build definitions > Build System :: artifact builds > Build System :: toolchains and platform integration > Build System :: automation jobs and tasks > > (Obviously this list isn't final and bikeshedding would be necessary.) > > I know we've had this conversation in the past. I agree there are merits > to a single bucket for everything. Part of this email is me following the > philosophy that you should always re-evaluate past decisions and see if > they are still justified. So, are there any changes since last time we > considered this that would warrant a Bugzilla restructure? > > _______________________________________________ > dev-builds mailing list > dev-builds@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-builds > >
_______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
