On Wed, Jun 8, 2016 at 10:22 AM, Benjamin Smedberg <benja...@smedbergs.us> wrote:
> > > 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. > These are all valid points. The disconnect between submitters lacking domain expertise and the wish of domain experts to apply deep classification are at odds and make our existing 2-tiered product-component system non-satisfactory for many. This probably isn't realistic, but I would prefer a system with broad components at the top level (e.g. "Firefox/Gecko build system") with per-component sub-categories/tags and any bug could belong to N sub-categories/tags (and possibly N top-level components). In other words, I want easy domain-specific tagging with the tags namespace managed by the "component admin." That's similar to Bugzilla keywords today and I'd probably be happy with a single build system component in our existing 2-tiered products-components model if keywords worked for tagging. But they don't because the keywords namespace contains a lot of junk/noise to be useful for per-component tagging. Plus keywords aren't self-service (you have to file a bug to get new keywords added). Even if you had that, you have the problem of submitters figuring out where things should go. It isn't obvious that `mach bootstrap` bugs go in the "build system" component. So now you need bug component descriptions to be highly verbose so appropriate components are surfaced in the components search box. Of course, changing component descriptions requires filing a bug and waiting for a BMO deploy. So there is stop energy in the form of process overhead there discouraging me from keeping my component descriptions up to date :/ > > 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? > Yup. "Build system" is today "mozilla-central build system" which itself is really short for "Firefox/Gecko build system [and related tools]." If we expand the monorepo and integrate something like Firefox for iOS into mozilla-central, now "mozilla-central build system" is ambiguous :/ That being said, the "Core" product is horrible for first-time Bugzilla users (seriously, what does "core" mean in the scope of "all of Mozilla") and "build config" isn't exactly intuitive either. Ontology and naming things is hard. I share your skepticism for a separate product. I would much prefer domain-specific tagging. But the closest usable solution we have for that today is bug components, hence why a separate product is tempting. > >> 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
