MozillaWiki

Media/WebRTC: Difference between revisions

Page Discussion

Media/WebRTC (view source)

Revision as of 19:04, 10 August 2023

3,013 bytes removed ,  10 August 2023
Update debugging link
(→‎Key Bugzilla Queries: separate backlog into two buckets (P1/P2 and P3 to P5))
(Update debugging link)
 
(30 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/1CorEYp Bugzilla Ranked "P1 and P2 - backlog="webRTC+" or "backlog"="tech-debt" list]
**Add the "Rank" Column to your results and sort on Rank
* [http://mzl.la/1Cos5lF Bugzilla Ranked "P3 to P5 - 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 140: 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/f36914322d6ceb1df8277c9fc8e0b200 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 164: 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]
Ng
139

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/1081149...1247568"