1406536 - Create New Product for Build Config and move existing components

Status: RESOLVED FIXED

(bugzilla.mozilla.org :: Administration, task, P1)

Description

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

Build Config Product

Rec Reviewers: the alias account [e-mail]

Security Groups: 

Port over the groups from Core and FFx

Components

Core
Firefox (may be combined with Core)
Unsupported Platforms
Thunderbird
Sea Monkey

Rationale is to get build system bugs out of the browser components to make assessment easier

Comment 1

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

If this meets with all yall's okay, I'd like to get this cued up.

Comment 2

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

core::mach belongs here too

Comment 3

[Gregory Szorc [:gps]]

I've said it many times before and I'll say it again "Core" and "Build Config" are not great names. If we're going to go through the trouble of renaming Core :: Build Config, I'd strongly prefer to ditch both "Core" and "Build Config." "Firefox" or "Firefox Desktop" is a better name for "Core" and "Build System" is better than "Build Config."

If we're going to establish a new Bugzilla product, I'd also encourage us to think long and hard about consolidating some other components with significant overlap with the build system. Mainly TaskCluster :: Task Configuration. I think there is general consensus that the Task Configuration component is a dumping grounds of random and it should exist outside of the TaskCluster product because it has little to do with the TaskCluster platform itself.

I'd like to propose a "[Firefox] Build and Automation" product with the following components:

* Bootstrap
* Build System
* Automation Configuration (or CI Configuration)
* Mach
* Build System (Unsupported Platforms)
* Thunderbird
* Sea Monkey

... or something along those lines.

I'd also love to have a central component where people can file "workflow" bugs without having to decipher which of the few dozen components is most appropriate. But I don't want to scope bloat this bug too much...

Comment 4

[Andrew Halberstadt [:ahal]]

Big +1

I'd suggest renaming the `Mach` one to `Mach Core` (which I know you just said is a bad name, but otherwise every problem with any mach command will be filed there).

We could also move Testing::Lint (and maybe Testing::Mozbase) to this new product, but I also don't want to scope bloat. If it gets made, I'd be happy to file follow-up bugs.

Comment 5

[Gregory Szorc [:gps]]

Yes, "mach" should probably get renamed to "Mach Core" to denote that it is supposed to be generic.

I also think linting and mozbase would belong in the new component.

mozharness could probably go there too.

How about a "Firefox Development Workflow" product? Although that would invite a larger discussion around consolidating code review, version control, and automation components/products. I'd be in favor of this consolidation. But I'm not sure how wed people are to the components. Unfortunately, I'm not seeing an obvious way to carve out a product that includes build and related tools while excluding overlapping functionality. The 2 tier product-component and bug is-a single component of Bugzilla just doesn't translate well to the reality of build, automation, and tools - which frequently have issues that span multiple components and can't be shoehorned into a strict classification ontology.

Given that Bugzilla is a critical gateway to reporting productivity-draining workflow problems, I think the most user friendly thing to do is have a single Product holding components related to Firefox development workflow. If nothing else, maybe we use that Product as a triage queue and move bugs to other components in different products. But at least we'd be able to point people at a single product for reporting their "I can't hack on Firefox" issue.

Comment 6

[:glob ✱]

imho "Firefox Development Workflow" is a bit of an oddball name; it's extremely broad and overlaps with other established products.  for example, bugzilla itself is part of the development workflow, however i wouldn't want it to be shifted to be a component under a workflow product.

a _component_ with that name which is used as a default bucket for triaging workflow related issues makes sense.
if we take that route we should expose it on the top level of the two bug entry forms.

a random/weird plan worth considering may be to make use of classifications, which allows for grouping of products.  this feature is not really used on bmo, resulting in it being minimally exposed in the ui.  it may be useful to split "firefox products" from "developer workflow products" and other things.

we could then work on the ui to bring some more focus on product classifications in an effort to simplify bug reporting (eg. allow users to report bugs by selecting just the high level classification, which automatically picks a triage product+component).

</massive_scope_creep>

+1 to a "Firefox Build and Automation" product with gps's components.

Comment 7

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

I'd like to get :gps' proposed organization out to dev-planning for comment, and then :dylan and I can implement.

Comment 8

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

Also, do we need to wait until after 57 to make this change?

Comment 9

[Gregory Szorc [:gps]]

(In reply to Emma Humphries ☕️ (she/her) [:emceeaich] (UTC-8) +needinfo me from comment #7)
> I'd like to get :gps' proposed organization out to dev-planning for comment,
> and then :dylan and I can implement.

I tossed together https://public.etherpad-mozilla.org/p/build-bug-components as a more concrete proposal. Please help me wordsmith it!(In reply to Emma Humphries ☕️ (she/her) [:emceeaich] (UTC-8) +needinfo me from comment #8)

> Also, do we need to wait until after 57 to make this change?

I'm not sure what the potential impact would be. But from where I sit I don't see a need to wait.

Comment 10

[Dustin J. Mitchell [:dustin] (he/him)]

> Automation Configuration (or CI Configuration)

This would be the new home for `Taskcluster :: Task Configuration`, right?

Comment 11

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

Yes.


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)

Comment 12

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

Discussed in dev-planning (and related) groups.

https://groups.google.com/forum/#!topic/mozilla.dev.planning/tTB-vZsllic

Okay to schedule this. 

Will file bugs for triage owners for components.

Comment 14

[Dustin J. Mitchell [:dustin] (he/him)]

Is this still moving along?  "Automation Task Configuration" is now officially a submodule of "Build Config", so I'd like to move it out of the Taskcluster product!  Anything I can do to help?

Comment 15

[Dylan Hardison [:dylan] (he/him)]

So sorry! I can do this tonight.

Comment 16

[Dylan Hardison [:dylan] (he/him)]

I need the user story to reflect exactly which actions should be taken for this bug -- having to read over comments would make this more error prone.

Comment 17

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

I moved what was in the etherpad into the user story.

Comment 18

[Dustin J. Mitchell [:dustin] (he/him)]

Not to sound like a broken record [1], but is this still moving along?

[1] "Records" were flat pieces of vinyl that encoded sounds in the texture on the surface, similar to a CD[2].  When "broken" they tended to repeat the same sound over and over.
[2] "CDs" were flat pieces of plastic that encoded sounds in a digital format in a metallized layer.

Comment 19

[Dylan Hardison [:dylan] (he/him)]

this is taking a bit longer because keeping a vpn connection open is apparently very hard for the latest version of OSX.

Comment 20

[Dylan Hardison [:dylan] (he/him)]

Since Build System is in the name, perhaps "Build System" component should be "General"?
"Firefox Build System and Automation"

Comment 21

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

(In reply to Dylan Hardison [:dylan] (he/him) from comment #20)
> Since Build System is in the name, perhaps "Build System" component should
> be "General"?
> "Firefox Build System and Automation"

Yes.

Comment 22

[Dylan Hardison [:dylan] (he/him)]

I'm asking for kmoir's opinion on the new product -- I know Testing :: , Task Cluster ::, Core :: are keen to get these components out of their products, but the suggested configuration should also be OK'd by the build system-y people.

Comment 23

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

:dylan +1

Comment 24

[Kim Moir [:kmoir] ET]

Comment 21 + the user story seems good to me.

Comment 25

[Dylan Hardison [:dylan] (he/him)]

I'm going to block out a few hours friday morning to do this.

Comment 26

[Dylan Hardison [:dylan] (he/him)]

Really the afternoon, but here we go.

Comment 27

[Dylan Hardison [:dylan] (he/him)]

Small regression: we hid tracking flags.
And if anyone changed the bugs, the tracking flags were removed.

I wipped up some sql and ran it. It seems fine now.

https://gist.github.com/dylanwh/504f31aac886d8fe6d8108ce5adf1361 is all tracking flags that changed today, just to check.

Comment 28

[Dylan Hardison [:dylan] (he/him)]

Attachment: the sql I ran today

Comment 29

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

Thank you for doing this!