Media/WebRTC

From MozillaWiki
Jump to: navigation, search

WebRTC is a free, open project that brings peer-to-peer real-time audio, video and data to the web without plugins, using open web standards. Checkout the WebRTC project page set up by Google for interesting links and details.

Releases & Notes

Triage Guidelines

The Product Backlog is continually maintained to ensure relative priorities are understood.

  • Priorities follow the Firefox Desktop Standard:

Go to WebRTC bugs to search for all open WebRTC bugs (including untriaged and unconfirmed bugs).

    • Priority 1 - Blocker, must-fix before shipping. Almost by definition of P1, the "affected" flags and "tracking" flags for the bug should be set when it's triaged.
    • Priority 2 - High priority backlog (bugs we are currently working on or will be working on next)
    • Priority 3 - Lower priority backlog
    • Priority 4 - Bugs we will accept patches for
    • Priority 5 - Parking lot (Bugs we do not plan to spend any time on)
  • RANK: The Rank field lets us prioritize bugs within a priority bucket (P2, P3, etc) in bugzilla. To have some rhyme/reason to the order - Rank should relate to Priority. The "Ranking" number does not need to be unique. Unless there is a reason to for a bug to be considered before (or after) others in the Priority bucket - the triager will default to mid-range value.
    • P1 Rank options=0-9, default 5
    • P2 Rank options=10-19, default 15
    • P3 Rank options=20-29, default 25
    • P4 Rank options=30-39, default 35
    • P5 Rank options=40-49, default 45
      • Note: P5 and "parking-lot"-labelled bugs are treated identically. We no longer use "parking-lot"; it is a legacy classification.

  • QE-Verify is a flag that developers should be setting. QE uses to filter which bugs they check.
    • "+" means that QE should look at the bug and it can be verified with human eyes
    • "-" means QE should not look at
      • Typically QE-verify"-" goes with "in-testsuite" being set to "+", to show testing via another method.

Filing a bug

  • Open a bug under Product:"Core" || Component: "WebRTC, WebRTC:Audio, WebRTC:Network or WebRTC:Signaling"
    • After triage, bugs will be marked "firefox-blocking", with a Priority, and a Rank
  • If there is a bug that should be considered for taking ASAP - you can mark "firefox-backlog"+
    • Before it can be given a Rank it should:
      • be in an actionable state
      • for defects, the problem is ready for Engineering or UX: diagnosis, measurement, design, or fixing
      • for feature requests or enhancements, it means that there's a clear problem statement or suggestion
      • has a difficulty/user-impact ratio low enough that we can reasonably expect to spend time fixing the bug within the next 6 months

Contributor Engagement

  • Add Whiteboard tag of [well filed] to the well filed bugs to acknowledge that we appreciate the effort and thoroughness
  • Add Whiteboard tag of [good first bug] for contributors to pick up

libwebrtc Updates

  • One can find documentation on the current libwebrtc fast-forward update process here.
  • The research and history on developing the fast-forward update process is documented here
  • The 2H2020 transition process is documented here.
  • The old libwebrtc update process is documented here.

Up-streaming Changes

  • One can find instructions for up-streaming changes here.

libsrtp Updates

Maintained by Cisco, libsrtp needs to be vendored periodically. A description of that process can be found here.

Project Status

Contacts and Useful Links

Meetings

Meeting Day of week Pacific Time Eastern Time Central European Time Vidyo Room Notes
"Weekly Stand-up" Wednesday 6:00AM - 6:30AM & 1:30 - 2:00 PM 9:00AM - 9:30PM & 4:30 - 5:00 PM 3:00PM - 3:30PM & - 10:30PM-11:00PM webRTC-Apps etherpad
  • Stand-up = 2 minutes on what have you been working on, planning to work on, and are you blocked. Bring-up topics for longer Discussion at end if needed.
    • Developers and active contributors only need to attend one of the two sessions each week. We have 2 sessions due to the number of very different time zones throughout the team.
    • please update the Stand-up Notes etherpad if you cannot make the meeting (even if it's just to say you're on PTO)
  • IETF Standards Meetings

Archived

Notes