Bugzilla:Meetings:2014-08-27

From MozillaWiki
Jump to: navigation, search
  1. Summary of the last meeting. Some follow-ups:
    • gerv requested putting priority on finishing the "api transition" wiki page, to provide clarity to developers regarding which API to develop against, and the medium and long term API plans
      • General idea is to use native rest if you are starting something new; if you're already using bzapi, either switch to native rest or move to bzapi-compat (or continue to use as is, and we'll redirect).
      • should note that REST v1 is "FROZEN" (which is more accurate than "deprecated").
      • mcote will write the api policy document (such as it is right now)
      • this document needs to be linked from all our current api docs
    • handling of security issues
      • sgreen emailed bugzilla-dev with suggestions (30 mins prior to meeting started)
      • once we have something solid, it needs to be hosted on bugzilla.org
  2. BMO would like to implement the following:
    • add a "minor update" boolean to all places where a bug can be changed (show_bug, bulk_updates, attachments, API param, ...)
    • if set, do not generate or send bugmail for that change
    • this is a change of the current policy:
      The Bugzilla Team has shied away from creating this option because it puts the power of determining what's "important" in the hand of the person changing the bug, not the person receiving the email notification
    • Prefer for this to be implemented upstream, but will make a bmo extension if the upstream policy is to remain
    • Decision: this will be an upstream feature, as long as there's an admin parameter with a group name AND a user preference which allows people to opt-in to minor updates.
  3. Bugzilla 5.0 roadmap.
    • Comment markdown is very nearly finished; might as well be included in 5.0.
    • One api key issue still needs to be fixed
    • After branching, we need to do the qa scripts prior to rc1
  4. GSoC project results.
    • As noted above, MarkDown was completed aside from a few minor tweaks.
    • YUI3 migration was not finished at the end of GSoC; however, we are considering the project successful due to the scope having been much bigger than predicted and lots of work done towards the end goal. glob will drive the completion of this
  5. Purpose and use of the Target Milestone field for the Bugzilla project
    • Some confusion over whether we should use Target Milestone or [Roadmap: ...] whiteboard flag to indicate that something is slated for a particular version.
    • Many bugs open with Target Milestone 5.0 that will not be in 5.0.
    • Our current release methodology is "release whatever is in trunk every 6 months or when there is a big feature that should go out". Thus it doesn't make much sense to target anything for a release past the next one.
    • Therefore our new policy will be
      • Target Milestone should only be set on open bugs when a bug has an assignee, i.e. is being actively worked on, or is an official blocker for that release.
      • Target Milestone will continue to be set to the next planned version when a patch is committed.
      • Target Milestone should only be set by the bug's assignee or a Bugzilla reviewer/approver.
      • mcote will document the policy and advertise.
  6. Documentation relicensing/restructuring update
    • All relicensing complete. Gerv working on new guide.
    • Quickstart guide didn't get much feedback; presume it's sufficient.
  7. QA test day
    • dkl will write up a plan and drive a "test day", similar to the triage party but with a focus on writing/updating test cases
Retrieved from "https://wiki.mozilla.org/index.php?title=Bugzilla:Meetings:2014-08-27&oldid=1009928"