Media/WebRTC: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(→‎Meetings: fix IETF link)
(Update debugging link)
 
(32 intermediate revisions by 7 users not shown)
Line 1: Line 1:
WebRTC is a free, open project that will bring peer-to-peer real-time audio, video and data to the web without plugins, using open web [[standards]].  Checkout the [http://www.webrtc.org/ WebRTC project page] set up by Google for interesting links and details.   
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 [http://www.webrtc.org/ WebRTC project page] set up by Google for interesting links and details.   


 
==Releases & Notes==
==Product Backlog==
 
<p> </p>
===Key Bugzilla Queries===
* [http://mzl.la/1e3Uwjq Bugzilla Ranked "backlog="webRTC+" or "backlog"="tech-debt" list]
**Add the "Rank" Column to your results and sort on Rank
***The option to "Change columns" is at bottom of search results
* [http://mzl.la/1e3Td3X Un-triaged webRTC bugs]
**Search based on Open webRTC component bugs that have no Backlog flag being set]
* [http://mzl.la/1S1TPFz Unconfirmed webRTC bugs]
**Search based on Open webRTC component bugs that have no Backlog flag being set]
 
<p> </p>
The goals of the Product Backlog and dynamic Planning are to:
**Simplify prioritization & planning so the team is always working on the most important features.
**Improve visibility to everyone to clear priorities - so we make the best decisions about the direction of the product (call out risks early, relative priorities, trade-offs).<p> </p>
 
==Releases==
*[https://wiki.mozilla.org/RapidRelease/Calendar Firefox Release Schedule Calendar]
*[https://wiki.mozilla.org/RapidRelease/Calendar Firefox Release Schedule Calendar]
*[https://wiki.mozilla.org/Media/WebRTC/ReleaseNotes/40 Firefox 40 WebRTC & Web Audio Release Notes]
*[https://wiki.mozilla.org/Media/WebRTC/ReleaseNotes Firefox WebRTC & Web Audio Release Notes]


===Firefox 41 (Nightly May 12, 2015 - June 29,2015  | Release uplift 2015-09-21) ===
===Triage Guidelines===
<p> </p>
The Product Backlog is continually maintained to ensure relative priorities are understood.
<bugzilla>
{
      "component":["WebRTC","WebRTC:%20Networking","WebRTC:%20Signaling","WebRTC:%20Audio/Video"],
        "bug_status":"RESOLVED",
        "include_fields":"id, summary, status, assigned_to",
        "target_milestone":"mozilla41"
}
</bugzilla>
<p> </p>


===Firefox 40 (Release uplift 2015-08-11) ===
* Priorities follow the Firefox Desktop Standard:
<p> </p>
Go to [https://wiki.mozilla.org/Media/Bugs#WebRTC_Bugzilla_Queries WebRTC bugs] to search for all open WebRTC bugs (including untriaged and unconfirmed bugs).
<bugzilla>
{
      "component":["WebRTC","WebRTC:%20Networking","WebRTC:%20Signaling","WebRTC:%20Audio/Video"],
        "bug_status":"RESOLVED",
        "include_fields":"id, summary, status, assigned_to",
        "target_milestone":"mozilla40"
}
</bugzilla>
<p> </p>
===Firefox 39 (Release uplift 2015-06-30)===
<p> </p>
<bugzilla>
{
      "component":["WebRTC","WebRTC:%20Networking","WebRTC:%20Signaling","WebRTC:%20Audio/Video"],
        "bug_status":"RESOLVED",
        "include_fields":"id, summary, status, assigned_to",
        "target_milestone":"mozilla39"
}
</bugzilla>
<p> </p>
===Firefox 38 (Release uplift 2015-05-12)===
<p> </p>
<bugzilla>
{
      "component":["WebRTC","WebRTC:%20Networking","WebRTC:%20Signaling","WebRTC:%20Audio/Video"],
        "bug_status":"RESOLVED",
        "include_fields":"id, summary, status, assigned_to",
        "target_milestone":"mozilla38"
}
</bugzilla>
<p> </p>
 
===Firefox 37 (Release uplift 2015-03-31)===
<p> </p>
<bugzilla>
{
      "component":["WebRTC","WebRTC:%20Networking","WebRTC:%20Signaling","WebRTC:%20Audio/Video"],
        "bug_status":"RESOLVED",
        "include_fields":"id, summary, status, assigned_to",
        "target_milestone":"mozilla37"
}
</bugzilla>
<p> </p>
 
==Repository Location ==
All the Platform WebRTC code and the Desktop Loop Client code is in mozilla-central. There are no other active repos.  If you are trying to come up to speed on any of our code, please feel free to come to #media on irc.mozilla.com.  #media is our "virtual hallway".  You can hang out, ask questions, and get answers.
 
==Product Backlog==
<p> </p>
All work related to the ongoing development and maintenance of webRTC are collected and prioritized in the Product Backlog.  The goals of the Product Backlog are to:
* Enable work to be prioritized so that the team is always working on the most important features.
* Support continual planning as the product emerges so the plan matches reality.
* Improve forecasts so that the stakeholders make the best decisions about the direction of the product.
<p> </p>


<p> </p>
** 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. 
'''Product Backlog''' 
** Priority 2 - High priority backlog (bugs we are currently working on or will be working on next)
* [http://mzl.la/1e3Uwjq Bugzilla Ranked "backlog="webRTC+" or "backlog"="tech-debt" list]
** Priority 3 - Lower priority backlog
**Add the "Rank" Column to your results and sort on Rank
** Priority 4 - Bugs we will accept patches for
***The option to "Change columns" is at bottom of search results
** Priority 5 - Parking lot (Bugs we do not plan to spend any time on)
* [http://mzl.la/1e3Td3X Un-triaged webRTC bugs]
**Search based on Open webRTC component bugs that have no Backlog flag being set]
* [http://mzl.la/1S1TPFz Unconfirmed webRTC bugs]
**Search based on Open webRTC component bugs that have no Backlog flag being set]


<p> </p>
*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.
===Triage Guidelines===
** P1  Rank options=0-9, default 5
The Product Backlog is continually maintained to ensure relative priorities are understood.  Individual priority may vary based circumstance.
** P2  Rank options=10-19, default 15
* Priorities follow the Firefox Desktop Standard:
** P3  Rank options=20-29, default 25
** Priority 1 - Blocker, must-fix before shipping.
** P4  Rank options=30-39, default 35
** Priority 2 - Major impact,  considering severity × probability. Not a blocker for shipping.
** P5  Rank options=40-49, default 45
** Priority 3 - Average Bug.  definitely a problem, but doesn't stop someone from using the product.
*** Note: P5 and "parking-lot"-labelled bugs are treated identically.  We no longer use "parking-lot"; it is a legacy classification.
** Priority 4 - Minor or polish bugs that are real issues (especially in aggregate) and annoying.
** Priority 5 - Low-impact. something we'd fix, but mostly only bothers the discerning user. Little impact on usability.
 
*RANK: As priority buckets start to have a large amount of bugs in them, the Rank field can be used to call attention to higher or lower rank and provide a way to sort easily 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 - default to mid-range value.
** P1  Rank options=1-19, default 15
** P2  Rank options=20-29, default 25
** P3  Rank options=30-39, default 35
** P4  Rank options=40-49, default 45
** P5  Rank options=50-59, default 55
** any that we don't think we can get to in the next 6 months should go in "backlog-" area


<p> </p>
<p> </p>
*The Blocking-Flag called "Backlog" track bugs that are approved or not for the Backlog ("webRTC+", "parking lot")
*QE-Verify is a flag that developers should be setting. QE uses to filter which bugs they check.
*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 that QE should look at the bug and it can be verified with human eyes
**"-" means QE should not look at
**"-" means QE should not look at
***Typically QE-verify"-" goes with "in-testsuite" being set to "+", to show testing via another method.
***Typically QE-verify"-" goes with "in-testsuite" being set to "+", to show testing via another method.
*"Points" should be set when known (if nothing set - assumed a "1" or very small).  Most relevant if taking a bigger bug so we know when bugs are large bits of work.


===Filing a bug===
===Filing a bug===
Line 138: Line 41:
*** has a difficulty/user-impact ratio low enough that we can reasonably expect to spend time fixing the bug within the next 6 months
*** has a difficulty/user-impact ratio low enough that we can reasonably expect to spend time fixing the bug within the next 6 months
<p> </p>
<p> </p>
'''Blocking FxOS'''
* [https://wiki.mozilla.org/B2G/Triage#Blocker_Triage_Guidelines%29 Blocking Guidelines relevant for FxOS bugs]
* Nominate bugs actually blocking FxOS release will set Project Flag: Blocking-B2G to the "{release number}?"


'''Contributor Engagement'''
'''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 [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
* 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 [[Media/WebRTC/libwebrtc_Update_Process|here]].
* The research and history on developing the fast-forward update process is documented [[Media/WebRTC/libwebrtc_Update_Process/automation_plan|here]]
* The 2H2020 transition process is documented [[Media/WebRTC/libwebrtc_Update_Process_Transition_Plan|here]].
* The old libwebrtc update process is documented [[Media/WebRTC/Legacy_Updating_Process|here]].
==Up-streaming Changes==
* One can find instructions for up-streaming changes [[Media/WebRTC/Up_streaming_Changes|here]].


==libsrtp Updates==
Maintained by Cisco, libsrtp needs to be vendored periodically. A description of that process can be found [[Meida/WebRTC/libsrtp_Update_Process|here]].
==Project Status ==
==Project Status ==
*[https://wiki.mozilla.org/Platform/Roadmap#WebRTC_.2F_WebAudio Summary of our plans for this year]
*[https://mozilla.aha.io/published/b40393012432847d857ee68299a8a82f?page=2 Detailed Roadmap], noting that the further out the more lose the targets are]
*[https://mozilla.aha.io/published/bfa7d4fb40b7d33d0442f351b6c8b9a6 More detailed Roadmap], noting that the further out the more lose the targets are]


==Contacts and Useful Links==
==Contacts and Useful Links==
*[https://mozilla.github.io/webrtc-landing/gum_test.html Click here] to try webRTC features in the Firefox browser
*[https://mozilla.github.io/webrtc-landing/gum_test.html Click here] to try WebRTC features in the Firefox browser
*[https://wiki.mozilla.org/Webrtc/contacts Contacts for webRTC]
*[https://wiki.mozilla.org/Webrtc/contacts Contacts for WebRTC]
*[https://wiki.mozilla.org/Webrtc/links Useful Links for webRTC]
*[https://wiki.mozilla.org/Webrtc/links Useful Links for WebRTC]
*[https://wiki.mozilla.org/Media/WebRTC/Tests Running tests for WebRTC in Firefox]
*[https://wiki.mozilla.org/Media/WebRTC/Logging Getting WebRTC logs in Firefox]
*[https://wiki.mozilla.org/Media/WebRTC/WebRTC_Debugging Debugging WebRTC Calls]
*[https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-04 IETF Draft: "Using ''Multicast DNS'' to protect '''privacy''' when exposing ''ICE'' candidates"] (AKA mDNS; Interactive Connectivity Establishment (ICE) [RFC 5245] protocol)
*[[Media/WebRTC/Privacy]]
*[[Media/WebRTC/Architecture]]
*[https://wiki.mozilla.org/index.php?search=Media%2FWebRTC%2F&title=Special%3ASearch&fulltext=1 etc.]


==Meetings==
==Meetings==
Line 162: Line 76:
! Meeting !! Day of week !! Pacific Time !! Eastern Time !! Central European Time !! Vidyo Room !! Notes
! 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 || webRTC-Apps || [https://etherpad.mozilla.org/webrtcweekly etherpad]
| "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 || [https://etherpad.mozilla.org/webrtcweekly 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.
* 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 [https://etherpad.mozilla.org/webrtcweekly Stand-up Notes etherpad] if you cannot make the meeting (even if it's just to say you're on PTO)
** please update the [https://etherpad.mozilla.org/webrtcweekly Stand-up Notes etherpad] if you cannot make the meeting (even if it's just to say you're on PTO)
* [http://ietf.org/ IETF Standards Meetings]
* [http://ietf.org/ IETF Standards Meetings]

Latest revision as of 19:04, 10 August 2023

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


Retrieved from "https://wiki.mozilla.org/index.php?title=Media/WebRTC&oldid=1247568"