BMO/Meetings/2013-03-11

From MozillaWiki
< BMO‎ | Meetings
Jump to: navigation, search

Bugzilla upgrade

Report on issues after Bugzilla 4.2 upgrade and move. - scl3 outage - There were some search issues - Frederic found a major search bug (in upstream bugzilla) that no one had found before the BMO upgrade

Clint: what more user-centric features might we build into bugzilla?

Discussion of TBPL2

    • Bugs that are intermittent failures. That info is going to be cached. Maybe a TBPL extension in Bugzilla, with a chart or stats graph that shows the amount of times that bug was marked. Instead of the flood for comments. When they have the system up and running we will revisit. They are now using the BzAPI to use the cached data . They hover over a bug ID and (expect some behavior) We need to have some TBPL information in the bug report without having it being in the comments.
    • All the oranges are public bugs.
    • Private bugs never came up in discussion.
    • Can use the bugzilla push mechanism to push updates to TBPL in real time.

They will be using Pulse and need it to work better In theory bugzilla will push info to pulse. there used to be a feature that was polling bugzilla eery 10 minutes for changes to any bugs and then publishing them into pulse for peopel to subscribe to. that was turned off without notice and we only found out a few months later. bringing it back online was dropped.

    • Pulse in general should be a priority for next quarter.
    • There is some code for an amqp broker
    • This would be very high traffic and IT was worried about that issue last year. We have much more traffic now.
  • Clint says we might want to not focus on doing this because it will be resource intensive. The buildbot traffic is more important in this area.

Autoland

  • rel eng is working more on Autoland. pushing into a queue of things to be landed. flag on autoland that says, high priority. otherwise goes into a queue. Main spike of activity is 2pm pacific. 2 people will be working on this project in Q2. https://wiki.mozilla.org/ReleaseEngineering:Autoland

User centered features

  • liz asks, who is the user in user centric? person logging into bugzilla?
  • clint: thinks first of developers and their use cases. landing patches, reviewing. Looking over bugs for their area.
  • qa users need advanced query page. Making saved queries somehow a default landing page.
  • clint says when he was in QA he made a wiki page with all his bugzilla queries, would click down the list
  • Can schedule it and get bugzilla to email the list to you -- whining. (run saved query every day or however often and email me the results.
  • Expose useful bugzilla features better. we are using bugzilla at a 2nd grade level.
  • Interview bugzilla power users, write some blog posts. (liz)

Diffs

  • Splinter. glob talks about this, large javascript app, does not integrate well with bugzilla.

was written as a proxy to bugzilla, in jquery,

>>> Splinter is a light-weight addition to Bugzilla that allows a patch reviewer to view a nicely formatted version of a patch in their web browser and add comments on particular sections. Subsequent reviewers or the original patch author can then view the comments inline in the Splinter display of the patch. <<<

  • glob forked patchreader, perl module, feed it a diff, interface through callbacks to get a standard unified view.

It ignores hg headers, git and hg headers and general format may not be represented currently

  • drop existing diff view, we have both that and splinter.
  • webkit, codereview.js Much nicer. could we convert to it?
  • patchreader would spit out html, coderreveiw.js could sit on top of that.
  • webkit uses ruby
  • should add another column to the commons table (or something)
  • Clint - this might be a good google summer of code project.
  • glob - what about a team-centric showbug page.
  • how do you define what a team is?
  • switch between different views and it's a sticky view?
  • smedberg - has a collection of people for crashkill, flash, what they like to see. layout and gfx team
  • have another way of looking at bugs, DOM people have another way.
  • mark c: We abuse the product component our product is a category and our components are products.

More ideas

  • canned comments mostly done - group sharing still needs work.
  • We need a map of workflow rules. built in. based on current issue's product/component, and status of bugs, they show on the left, choices of the next actions possible on the bug.
    • for example if there's a patch, it's been submitted for review, here's what happens next
    • map out the workflow. (liz and dkl)
    • for example justdave's nagios status hardcoded thing
  • Ready flag. For things in between new and assigned. "ready" to be worked on by dev.
    • What about instead, making all new bugs go to Unconfirmed.
    • Does new mean new, or new mean ready?
    • Triagers and qa want the untriaged/new stuff (in firefox will automatically be in Untriaged components)
    • Is there a way to restrict query to "new to bugzilla"? (no)
    • But you don't necessarily need that for Firefox at least since they go to Untriaged
  • Component watching - summer of code project ? should include more stuff, is too short of a project

User profiles

  • We could build a basic user profile. As a user, I want to look at other users, to have some idea of the depth of their knowledge and level of activity.
  • Could add a profile field for link to mozillians. Mozillians team would like that!
  • The profile does not need to be "social" and we will not have Bugzilla buddies. Dodge that bullet!
  • My own user dashboard is about my current state.
    • My view of another person's profile might be more like an high level overview of their bugzilla history.
    • Summary of how many bugs reported, patches submitted, comments made, flags changed, bugs poked...
  • There is already a user activity report. Click on their email address, you get a context menu. When you click on someone's name in the comments, you get a tooltip for Activity report, email, edit user. This links you to the regular Reports page with some default options filled out. Hilariously half of us did not know about this. It would make a fine blog post.
  • glob: account information" doesn't show any information about the account (i would call that "name and password"); "permissions" should probably be renamed "account information", and then we can drop stats on that page.  although that's fodder for another bug i suspect... it would be nice to see a "# bugs reported, # comments, blah blah" page for your own bugzilla account.
  • Efficient bugzilla useage. We should give a (group) talk on this at the next MozThingSummitEventCamp.