Topline goal ideas for Bugzilla based on what a few sites are doing or needing

Dylan Hardison dylan at mozilla.com
Thu Dec 3 14:32:42 UTC 2015


On Thu, Dec 3, 2015 at 5:04 AM, Gervase Markham <gerv at mozilla.org> wrote:
> Hi Dylan,
>
> Thanks for doing this research :-)

My pleasure. My hope is we can make a roadmap that meets the needs of
many Bugzillas
and is more than strictly maintenance work.

> On 30/11/15 03:14, Dylan Hardison wrote:
>> I also ran a few simple queries against open bugs on BMO, ordered by
>> the number of CC's by specific accounts. Many of those bugs are very
>> old, have very little activity
>> and (in my humble opinion) examples of "perfect is the enemy of good".
>
> As in, what the bug requests is too perfect and so has not been
> actioned? Or in the bug, people have argued for something simple and
> been rebuffed?

Both of those situations happen. Usually new work gets blocked by
re-architecture requests as well.
Let's not dwell on that though. We can just fix things moving forward.

>> What I've compiled (which is not much) is now available on the wiki page:
>> https://wiki.mozilla.org/Bugzilla:Ideas
>
> The ideas are:
>
> 1) Webhooks or Push Connector API
>
> -- Can you explain what you mean by "webhooks" in this context, and
> expand a bit more on what this would look like and what it would let you do?
The ability of a user to subscribe to bug changes, so that when a
change happens an (out of process, as in bugmail or the push connector
itself)
HTTP request is made. You could use this to hook up changes in a
product to invoke a CI system or so on.
It is something we're going to be doing to BMO using the push connector.

I think for now we can change this item to just "adopt the push
connector" (although it will require a few tweaks to be extensible).

> 2) Auth Stack Changes
>
> -- If the auth stack is getting in the way of people actually using it
> to authenticate things, we should fix that, yes. BMO has some plans in
> this area, I believe - what are they, do you know?

The entire auth stack below the level of Bugzilla->login should be simplified.
BGO has an open bug for openid, BRC has an open bug for openid (and
they also want to use SAML).

Meanwhile, the changes to auth I'm doing for BMO are purely a
simplification of what is there.
The bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1215314.

Right now, auth looks a bit like this:
https://hardison.net/~dylan/bugzilla-auth/internals/auth.html#execution-path-overview

I would like to survey who is using the LDAP and RADIUS auth providers
and if they couldn't be migrated to something
more contemporary.

> 3) Modernize UI
>
> -- I think we should definitely start from glob's work. Does it support
> mobile?

Bug Modal explicitly does not, although IMHO it looks better on mobile
than the current system.
Work on the header and footer would help that.

I am looking into the feasibility of using bzdeck against 5.0+ bugzillas.
I would like talking about it to be on the agenda for the December 23rd meeting.

I think redhat is looking into redoing their show_bug as well, taking
a different direction by scrapping template
toolkit. Devel::NYTProf indicates TT2 is a significant performance problem.

I think we need a separate page for performance improvements (I have a
long list of these. most need benchmarking)

> 4) Advanced Search UI Problems
>
> -- By "advanced" you mean the Boolean Charts stuff at the bottom of the
> search page (as it used to be called)? This is indeed a great candidate
> for an API-driven dynamic query builder rather than a bunch of dropdowns.

once again, I'm just highlighting what (a couple) of bugzilla sites
are planning on doing.

> 5) Product/Component Watching
>
> -- I agree the extension should be shipped with core or be reimplemented
> in core.



More information about the developers mailing list