Closed Bug 729710 Opened 13 years ago Closed 13 years ago

Need to add Bugzilla components for WebRTC

Categories

(bugzilla.mozilla.org :: Administration, task)

Production
task
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: jduell.mcbugs, Assigned: dkl)

References

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: nobody → dkl
Status: NEW → ASSIGNED
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.
(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
All done dkl
Status: ASSIGNED → RESOLVED
Closed: 13 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
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.