Whistler Bugzilla

Agenda

mark: Issues with code in mozilla-central?
larsberg: Right now, I manually handle porting issues between bugzilla and create issues on the Rust side.
mark: Related to hg, there's a challenge. Maybe move stuff to hg?
larsberg: We keep it all in Github. m-c will probably vendor this.
mark: How do you track all these issues across repos?
larsberg: It's painful.
mark: Considering having dynamic panels for PR reviews inside of bugzilla. Then, it'd centralize stuff for the tracking & project management stuff. If you already split the code, maybe the issues aren't a big deal.
mark: How do you handle these issues? There's a program management office now.
larsberg: I handle it all manually.
mark: SHould have them.

mark: It's our future for Gecko. Have some GH support that's almost finished. Mainly to help people who want to do gecko dev in GH to import their PR into MozReview. Gives us autolanding, try, inbound, etc. Have talked to people who might want to use ReviewBoard. We can support GH repos. Not all the extra machinery, but it's not bad. Just add a repo to ReviewBoard.
jack: Lots of them don't support in-place rebases or history rewrites. How does this work?
mark: For m-c, that's exactly what we're doing. Supporting & highly encouraging micro-commits, etc. Want them split up into lots of pieces.
larsberg: Handling rebases against master has been a huge issue for us.
mark: One of our core principles here (interdiffs, etc.).
glob: Have people working on the review tool here.
mark: Yes, 3-4 people here right now. Doubt the GH support is baked in yet, but it's on the roadmap.
larsberg: We use reviewable right now, which is pretty good for handling changes, but has some perf issues.
jack: Used to use Critic which had more features, but couldn't handle rebases well.

glob: How does it work?
larsberg: Totally manual, especially for thing like the Rust compiler.
glob: Could automate some of that. We have scripts that do it.
larsberg: Maybe for rust-url we should figure out if we do something bi-directional there.
jack: How do you do skia right now?
glob: There's no standardized way right now or process to follow.
mark: With rust-url - probalby just do code drops into Gecko. So maybe just open in bugzilla and have them appear in the GH repo?
larsberg: As long as it works with the project managment / tracking stuff works.
jack: Should be easy to hook up to GH API, just for checking if things are closed?
glob: Generally, it's done en mass - there's a data warehouse that they do mining on. It won't scale.
jack: Maybe just refresh the info nightly from GH or something? Could also have webhooks.
mark: Question is if the program management only cares about the bugzilla issues or if they'd want to see the community members, too? I think they just care about bugzilla.

jack: We get pressure to move our issues from GH to bugzilla. You can log in with GH, right?
mark: yes.
jack: The other issue is that the bugzilla entry forms are hideous for logging bugs...
glob: That's just for devs. The guider entry forms are much more sane.
jack: There are definitely some issues with GH. e.g., you must have commit access to the repo to be assigned or close the issues. Unforutnately left out of the new fine-grained permissions. Makes us curious about bugzilla, but everything is so painless on GH that it's hard.
glob: The UX is definitely the most-raised pain point in bugzilla. We're also working on a brand new view of bugs, better grouping, etc. Will do the same thing with the advanced form.
larsberg: New form looks nice. Can we also attach web resources? GH doesn't let us.
glob: Yes.
jack: Custom forms?
glob: Yes. Should have your own product.
jack: Can we scope the UI to just servo.
mark: Yeah, our search UI is bad. Could do a one-off page.
glob: No way for a user to say to scope to a single product by default.
jack: Also, the pulldowns are better in GH.
glob: Yeah, we're working on better UI in Q3.
jack: Also often looking for all bugs I've filed, which requires a custom saved query.

jack: We love being able to edit so easily. There's the # and the issue numbers propagate immediately. Same for @-mentions. Plus, @-mentions CC you on a bug.
glob: We want to add those kinds of dropdowns and those auto CC-ing.
jack: Doesn't work for :-names?
glob: Nope, it's just a convention and is not required. Bugzilla is an OSS project, so we can't just add it.
jack: Does everybody use a fork? Can you add your own stuff?
mark: People usually clone from source and install it. RedHat, etc. do fork and keep it private. There is a flat basically 6,000 installations of bugzilla that are updated and that's pretty stable. The big projects, though, are big consumers. They've mainly skinned, so there are basically zero upstream contributions. RedHat is the only one that contributes stuff back.
jack: Migrations?
glob: We have scripts, but it has to be case-by-case to map usernames over...
dylan: Maybe we could auto-create accounts for the GH accounts. If I see the e-mail address, I can create an empty account and they can log in...
glob: Not a fan of creating them in bulk due to the privacy policy agreement.
jack: More restrictive than github?
glob: Your e-mail address is your userid and is publicly visible.
jack: If I sign in with GH, I have to have a public e-mail address?
dylan: No, we can still find it.
larsberg: We required things to be public before, due to autolander script requirements.

mark: Did you write it?
larsberg: The original one we wrote, but the new one is from the community (homu).
jack: The old one was really bad; much nicer now with GH events. Our autolander infra would have to be rewritten to handle bugzilla, which is a lot of work.

glob: We have can mark stuff as spam and enough reports will disable the account. Australis, spam-related, etc.
jack: We only have IRC crazies right now; I hope we don't see them in our issues.