All users were logged out of Bugzilla on October 13th, 2018

Need to add Bugzilla components for WebRTC

RESOLVED FIXED

Status

()

RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: jduell, Assigned: dkl)

Tracking

Production

Firefox Tracking Flags

(Not tracked)

Details

WebRTC needs one or probably more bugzilla components: networking, audio, video, UI (in Firefox mostly), signaling + negotiation.

I don't know bugzilla conventions well enough to say if these should become components of existing things ("Core::Networking:WebRTC) or if WebRTC should have it's own subcomponents ("WebRTC::Networking").

Cc-ing randell who is the webRTC mastermind.
(Assignee)

Updated

7 years ago
Assignee: nobody → dkl
Status: NEW → ASSIGNED

Updated

7 years ago
Blocks: 665909
I'm not entirely familiar with the different aspects of WebRTC, but in my experience it's best to start off with a loose Bugzilla taxonomy, and only get more specific or fine-grainde when you have experience dealing with real bugs that shows it would be useful.

Would it not be feasible to start off with a single Core::WebRTC component to cover WebRTC issues in general? Firefox UI bugs can live in Firefox::General, and bugs that are very specifically about existing Networking or Video/Audio code can go in those existing components.
It's a weird case because we're absorbing a *lot* of code.  I suspect we'll want at least some rough breakdowns into networking, video, etc (Randell is the one who'd know the list).  I want to follow networking RTC issues w/o getting all webRTC video bugs, etc.   And the code is separate enough from the rest of networking that I imagine some people may want to follow networking::webRTC or webRTC:networking w/o getting all of the Core::networking traffic.
Right - it is ~500K LOC (.h and .c*), 15MB.  I wouldn't want a lot of components, but a couple might be good.  

Core:: WebRTC: General   (or just Core:: WebRTC)
Core:: WebRTC: Networking
Core:: WebRTC: Audio/Video
Core:: WebRTC: Signaling

should be enough, IMHO.  Maybe we'll need a UI component, but I wouldn't worry about it now.
Oh, and the signalling library we're pulling in (before we pare it down a lot) is ~200K lines. A *lot* of that won't be needed, though, but I wouldn't be surprised if we end up with another 50-100K lines.
(Assignee)

Comment 5

7 years ago
(In reply to Randell Jesup [:jesup] from comment #3)
> Core:: WebRTC: General   (or just Core:: WebRTC)
> Core:: WebRTC: Networking
> Core:: WebRTC: Audio/Video
> Core:: WebRTC: Signaling

Thanks. The last thing i need to finish this out is a brief description for each one that is displayed to the user when they select the component.

dkl
Core:: WebRTC: General   (or just Core:: WebRTC)
General bugs associated with WebRTC

Core:: WebRTC: Networking
Bugs in the networking portions of WebRTC (PeerConnection dataChannels, SCTP, DTLS, SRTP, ICE, TURN, STUN, etc)

Core:: WebRTC: Audio/Video
Bugs in WebRTC audio and video capture, handling, echo cancellation, encoding, and playback

Core:: WebRTC: Signaling
Bugs in WebRTC call-setup and re-negotiation code, in particular JSEP and SDP handling
(Assignee)

Comment 7

7 years ago
All done

dkl
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Please rename "WebRTC: General" to "WebRTC" to match existing naming scheme.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to Reed Loden [:reed] (very busy) from comment #8)
> Please rename "WebRTC: General" to "WebRTC" to match existing naming scheme.

good catch; updated.
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.