http://blog.gmane.org/gmane.comp.mozilla.devel.seamonkey hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/26706 <pre>Our next combined channel meeting is today &lt; at &gt; 2:00 PM PT. Details: * Mozilla Mountain View: Warp Core conf room, 3rd floor * Meeting notes &amp; triage queries: https://wiki.mozilla.org/Firefox/Channels/Meetings/2012-05-24 * Vidyo Room: Warp Core * Vidyo Guest URL: https://v.mozilla.com/flex.html?roomdirect.html&amp;key=UK1zyrd7Vhym (please mute) * Join irc.mozilla.org #planning for back channel Cheers, Lukas </pre> Lukas Blakk 2012-05-24T19:14:49 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/26705 <pre>Sync will have its regular Rapid Release meeting, where we go over what is coming in upcoming releases, and the potential impact on stakeholders. where: vidyo room 'Services' when: 14:00 (2pm) pacific wiki: https://wiki.mozilla.org/Services/Meetings/RapidRelease/2012-05-23 </pre> Allison Naaktgeboren 2012-05-23T18:52:06 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/26704 <pre>Here's the proposed landing plan for WebRTC. It will land in stages over the next month+, as portions as ready and as reviews are completed. Undoubtedly this will be modified significantly along the way, especially the guesses as to reviewers. roc has already seen this; his initial comments are included. -------------------------------------------------------------- Overview of plan to land webrtc code from Alder to Mozilla-Central: 1st tranche (preffed off in configure.in) - to land ASAP Build system changes: configure.in client.mk gyp-&gt;makefile converter Import script media/webrtc/trunk/: src tools build test (perhaps minus test/data for now until we enable tests) testing Total size: ~500K lines of .cc &amp; .h files (plus a few .gyp files and .py files for gyp, etc), plus tests 2nd tranche: (might be swapped with some of 3rd tranche depending on resources) (June 1-Jun-8) getUserMedia with Webrtc backend (for non-mobile) (initial) tests for getUserMedia flip pref Must be green on all devices (even if disabled for some targets like Android &amp; B2G) 3rd tranche: (June 29) SCTP/DataChannel (netwerk) transport service (ICE/TURN and p2p transport from EKR) signaling (sipcc) This is large, on the order of 200-250K lines. libjingle (very partial, minus stuff overlapped by signaling work - mostly talk/phone or base) Might not be needed at all, or a very small subset. libsrtp (probably as media/libsrtp) libyuv (probably as media/libyuv) Parts of this will likely land directly. more tests 4th tranche (July 13) peerconnection DOM work more tests --------------- Reviews needed: We will NOT be line-by-line reviewing 700+K lines of code. This is largely imported code. We will be importing versions chosen for stable snapshots by Chrome in order to best leverage Google's testing and security work. This also will let us watch any important bugfixes and security fixes to those 'stable' pulls. Updates on m-c after landing will be pulled from Chrome stable revs, but with perhaps a bit more examination of the changes as the size of the patches goes down. Updates to third-party code (libyuv, libsrtp) to be handled in conjunction with webrtc.org updates We will be doing normal line-by-line reviewing of code we wrote and modifications to the imported code. Security reviews: To be negotiated with Security team; done in phases and leveraging Google's work. Most likely soft spots will be DOM and signaling. Maybe DataChannel. We need to tie into Google's security team We'll need protocol fuzzing Avoid too much overlap with Google's testing dveditz indicates they have a contractor in Germany? who has experience with fuzzing Protocols available for fuzzing: RTP/RTCP SRTP/SRTCP (libsrtp) DTLS SCTP/DTLS ICE STUN TURN VP8 and OPUS packetization (may not be much there) NetEQ/etc (fuzz by modifying jitter and loss) JSEP/SDP User privacy protection and controlling the attack surface of the browser will be important considerations. Initial landing: Make system, internal build tools (gyp-&gt;make) Reviewers: khuey, glandium?, bsmedberg?, release-eng, others TBD Review of the import process (and script) Reviewers: ted, myk??, glandium?, others TBD gyp file changes to webrtc Reviewers: ted, khuey, glandium custom Windows capture code Reviewer: cpearce (already reviewed except for minor #include issue) License review Reviewer: gerv Overall ok from primary leads of Media, Security, Platform. Approvals: roc, dveditz?/akeybl?/TBD, JP? Flipping pref for getUserMedia(): Review getUserMedia() Reviewers: DOM Team member (khuey?), sicking? Review capture-path of media/webrtc/trunk/src This is high-level review of the imported code before turning it on Reviewers: jesup, derf, ekr, ? Review device access code audio and video, all main platforms This is high-level review of the imported code before turning it on Reviewer: TBD Review rendering paths for preview Reviewers: TBD (fabrice?) Later: Opus support in WebRTC Reviewers: jesup, derf, ? Review protocol paths at a high level (not sure this makes much sense): rtp/rtcp/srtp Reviewer: jesup congestion Reviewer: mcmanus JSEP/SDP Reviewers: ekr, jesup, ehugg jitter buffers/NetEq/etc Reviewers: jesup, jean-marc, ? AEC (and CNG, etc) Reviewers: jean-marc, derf, jesup DataChannels Reviewers: mcmanus/biesi (netwerk/sctp), jst/? (DOM) Review libsrtp and libyuv. Open question: do we move them to media/libsrtp &amp; libyuv? probably makes sense Note: pure import, no line by line review Reviewers: ekr, derf, jesup, graphics team member? Signaling: (JSEP/SDP) This is sipcc - ~200K lines, and a fair amount of modifications Also, a fair bit of code was added to sipcc after it was open-sourced and before it was imported from ikran. That code should get higher scrutiny. Reviewers: jesup, ekr, derf, mcmanus(?), ehugg, roc? PeerConnection DOM Reviewers: khuey, jst? Updates: We'll take updates from 'stable' branches of Chromium's webrtc pulls, by pulling the same changesets. We should watch for changes applied after they're moved to Chrome, and individually review those. Land stuff separately (and review) wherever possible, as MediaStreams did. DataChannel getUserMedia() Libraries for transport service </pre> Randell Jesup 2012-05-24T09:46:20 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/26703 <pre> What does this mean for pushing older trees to try? Will that break? -Boris </pre> Boris Zbarsky 2012-05-24T16:39:05 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/26702 <pre>tl;dr https://hg.mozilla.org/mozilla-central/rev/71075a6e5d4d needs to be in your tree or buildbot builds will soon fail. https://bugzilla.mozilla.org/show_bug.cgi?id=748490 created the concept "testing JS modules." These are JavaScript files that can be loaded/imported as modules but are only available in testing code, not in released packages. While I'm mentioning it, I should say that you should consider using this instead of "head" files to provide common functionality to your test code because it is an architecturally superior solution. https://developer.mozilla.org/en/Developing_Tests#JavaScript_Test-Only_Modules has more. To support this new feature, we need to package these test files in the tests archive produced during packaging. And, we need to configure buildbot to extract this directory when it runs tests. Unfortunately, because of the way things work, if the "modules" directory is missing from the tests package and buildbot tries to extract this directory, the command will return a non-0 exit code and the build step will fail. In https://bugzilla.mozilla.org/show_bug.cgi?id=755339, we added an empty "modules" directory to the tests archive. And, that trivial changeset (https://hg.mozilla.org/mozilla-central/rev/71075a6e5d4d) has been pushed out to central, inbound, aurora, beta, esr, and release. Sometime in the near future, buildbot will be updated (https://bugzilla.mozilla.org/show_bug.cgi?id=757460). Once it is, if the tree being built does not produce test archives with the "modules" directory, things will fail when extracting the tests archive. So, to prevent build breakage, you'll need to ensure your tree picks up 71075a6e5d4d from mozilla-central. If you do nothing, your tree may appear to break randomly (when buildbot updated are deployed). Yes, everyone realizes this is a silly hoop to jump through. There are comments in bug 757460 regarding how this could be eliminated in the future. They are out of scope for this task, however. If you have any questions, please direct them to bug 757460. Gregory/gps </pre> Gregory Szorc 2012-05-24T16:17:11 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/26701 <pre> No, since that's all in the chrome code that will go on top of this. (I'll verify, but there shouldn't be any I can think of.) </pre> Randell Jesup 2012-05-24T14:50:16 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/26700 <pre> See bug 'webrtc'; master tracking bug, and view the dependency tree. (bug 665909) </pre> Randell Jesup 2012-05-24T14:49:06 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/26699 <pre>I'm really looking forward to this, as I already have a "production" WebRTC application running on Chrome Canary. Would really like a second browser choice in case Google pushes down a breaking update (which would be totally reasonable under the Canary release guidelines). We used the getUserMedia() streaming video stuff to build a "photo booth" application. I tried figuring out which bugs the WebRTC was implemented in -- it looks like is being largely developed somewhere else than Bugzilla? I'm now tracking Bug 749889 - Land necessary portion of media/webrtc for getUserMedia on m-c. Wes On 24 May 2012 05:53, Randell Jesup &lt;rjesup.news&lt; at &gt;jesup.org&gt; wrote: </pre> Wes Garland 2012-05-24T12:53:38 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/26698 <pre>Not really related to the landing plan, but as this is external code: Does that come with strings that we need to localize, like error messages or stuff? Axel </pre> Axel Hecht 2012-05-24T12:00:24 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/26697 <pre>Here's the proposed landing plan for WebRTC. It will land in stages over the next month+, as portions as ready and as reviews are completed. Undoubtedly this will be modified significantly along the way, especially the guesses as to reviewers. roc has already seen this; his initial comments are included. -------------------------------------------------------------- Overview of plan to land webrtc code from Alder to Mozilla-Central: 1st tranche (preffed off in configure.in) - to land ASAP Build system changes: configure.in client.mk gyp-&gt;makefile converter Import script media/webrtc/trunk/: src tools build test (perhaps minus test/data for now until we enable tests) testing Total size: ~500K lines of .cc &amp; .h files (plus a few .gyp files and .py files for gyp, etc), plus tests 2nd tranche: (might be swapped with some of 3rd tranche depending on resources) (June 1-Jun-8) getUserMedia with Webrtc backend (for non-mobile) (initial) tests for getUserMedia flip pref Must be green on all devices (even if disabled for some targets like Android &amp; B2G) 3rd tranche: (June 29) SCTP/DataChannel (netwerk) transport service (ICE/TURN and p2p transport from EKR) signaling (sipcc) This is large, on the order of 200-250K lines. libjingle (very partial, minus stuff overlapped by signaling work - mostly talk/phone or base) Might not be needed at all, or a very small subset. libsrtp (probably as media/libsrtp) libyuv (probably as media/libyuv) Parts of this will likely land directly. more tests 4th tranche (July 13) peerconnection DOM work more tests --------------- Reviews needed: We will NOT be line-by-line reviewing 700+K lines of code. This is largely imported code. We will be importing versions chosen for stable snapshots by Chrome in order to best leverage Google's testing and security work. This also will let us watch any important bugfixes and security fixes to those 'stable' pulls. Updates on m-c after landing will be pulled from Chrome stable revs, but with perhaps a bit more examination of the changes as the size of the patches goes down. Updates to third-party code (libyuv, libsrtp) to be handled in conjunction with webrtc.org updates We will be doing normal line-by-line reviewing of code we wrote and modifications to the imported code. Security reviews: To be negotiated with Security team; done in phases and leveraging Google's work. Most likely soft spots will be DOM and signaling. Maybe DataChannel. We need to tie into Google's security team We'll need protocol fuzzing Avoid too much overlap with Google's testing dveditz indicates they have a contractor in Germany? who has experience with fuzzing Protocols available for fuzzing: RTP/RTCP SRTP/SRTCP (libsrtp) DTLS SCTP/DTLS ICE STUN TURN VP8 and OPUS packetization (may not be much there) NetEQ/etc (fuzz by modifying jitter and loss) JSEP/SDP User privacy protection and controlling the attack surface of the browser will be important considerations. Initial landing: Make system, internal build tools (gyp-&gt;make) Reviewers: khuey, glandium?, bsmedberg?, release-eng, others TBD Review of the import process (and script) Reviewers: ted, myk??, glandium?, others TBD gyp file changes to webrtc Reviewers: ted, khuey, glandium custom Windows capture code Reviewer: cpearce (already reviewed except for minor #include issue) License review Reviewer: gerv Overall ok from primary leads of Media, Security, Platform. Approvals: roc, dveditz?/akeybl?/TBD, JP? Flipping pref for getUserMedia(): Review getUserMedia() Reviewers: DOM Team member (khuey?), sicking? Review capture-path of media/webrtc/trunk/src This is high-level review of the imported code before turning it on Reviewers: jesup, derf, ekr, ? Review device access code audio and video, all main platforms This is high-level review of the imported code before turning it on Reviewer: TBD Review rendering paths for preview Reviewers: TBD (fabrice?) Later: Opus support in WebRTC Reviewers: jesup, derf, ? Review protocol paths at a high level (not sure this makes much sense): rtp/rtcp/srtp Reviewer: jesup congestion Reviewer: mcmanus JSEP/SDP Reviewers: ekr, jesup, ehugg jitter buffers/NetEq/etc Reviewers: jesup, jean-marc, ? AEC (and CNG, etc) Reviewers: jean-marc, derf, jesup DataChannels Reviewers: mcmanus/biesi (netwerk/sctp), jst/? (DOM) Review libsrtp and libyuv. Open question: do we move them to media/libsrtp &amp; libyuv? probably makes sense Note: pure import, no line by line review Reviewers: ekr, derf, jesup, graphics team member? Signaling: (JSEP/SDP) This is sipcc - ~200K lines, and a fair amount of modifications Also, a fair bit of code was added to sipcc after it was open-sourced and before it was imported from ikran. That code should get higher scrutiny. Reviewers: jesup, ekr, derf, mcmanus(?), ehugg, roc? PeerConnection DOM Reviewers: khuey, jst? Updates: We'll take updates from 'stable' branches of Chromium's webrtc pulls, by pulling the same changesets. We should watch for changes applied after they're moved to Chrome, and individually review those. Land stuff separately (and review) wherever possible, as MediaStreams did. DataChannel getUserMedia() Libraries for transport service </pre> Randell Jesup 2012-05-24T09:53:26 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/26696 <pre>Our weekly Firefox Developer Tools meeting is on Thursday, May 24 Agenda at: https://wiki.mozilla.org/DevTools/2012-05-24 - 10:00am Pacific, 1:00pm Eastern, 17:00 UTC - 650-903-0800 or 650-215-1282 x92 Conf# 99459 - 1-800-707-2533 (pin 369) Conf# 99459 (US) - #devtools on irc.mozilla.org &lt;irc://irc.mozilla.org/devtools&gt; for backchannel </pre> Dave Camp 2012-05-23T19:55:15 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/26695 <pre>We are working on a Triage page (still in progress) - https://wiki.mozilla.org/Kilimanjaro/Triage. Details: * Mozilla Mountain View: Peanut Butter &amp; Jelly conf room, 3rd floor * Dial-in: conference# 95346 * US/International: +1 650 903 0800 x92 Conf# 95346 * US toll free: +1 800 707 2533 (pin 369) Conf# 95346 * Canada: +1 416 848 3114 x92 Conf# 95346 * Vidyo: PB&amp;J * Join irc.mozilla.org #planning for back channel </pre> Sheila Mooney 2012-05-23T19:14:10 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/26694 <pre> Those early milestones were each in the context of a particular event (MWC, JSConf), so any work that is marked "done" is meaningful only for that event. As noted for Milestone 3, we're tracking all WebAPIs and apps here: http://j.mp/Lb5ptN It tracks design, UX, development, security reviews and testing (and more). It's still not complete in some areas - let me know if there are particular things you need to know that aren't visible there. </pre> Dietrich Ayala 2012-05-23T16:02:22 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/26693 <pre> That appears to be out-dated. We have b2g and gaia mailing lists now. Why do you think it's important what name appears in these URLs? Note that some repositories have already moved; for example, the main B2G repository is now https://github.com/mozilla-b2g/B2G. _______________________________________________ dev-planning mailing list dev-planning&lt; at &gt;lists.mozilla.org https://lists.mozilla.org/listinfo/dev-planning </pre> Justin Lebar 2012-05-23T14:48:39 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/26692 <pre>I didn't see a response to chofmann's questions (below). I'm also interested in the answers. Ping. Lawrence ----- Original Message ----- </pre> Lawrence Mandel 2012-05-23T14:39:18 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/26691 <pre>So we are going to experiment with some new triage times starting tomorrow. We will start with 1/2 hr at 1:00pm PT on Mon/Wed and see how that works. Ideally, once we get going we won't need to do this as much but the more organized group triage is necessary initially while we flush out the requirements. I totally understand that some people might have teams meetings and such at that time. If it makes you feel better, I had to move mine. It's simply impossible to find a time that works for everyone. We are hoping that most people can make it to one of the slots or can move things around to clear up 1/2 hr. I will send out a calendar invite to a group of usual suspects. If I didn't include you and you want to be added, please ping me. I will also send a reminder prior to each meeting with the queries. Details: * Mozilla Mountain View: Peanut Butter &amp; Jelly conf room, 3rd floor * Dial-in: conference# 95346 * US/International: +1 650 903 0800 x92 Conf# 95346 * US toll free: +1 800 707 2533 (pin 369) Conf# 95346 * Canada: +1 416 848 3114 x92 Conf# 95346 * Vidyo: PB&amp;J * Join irc.mozilla.org #planning for back channel </pre> Sheila Mooney 2012-05-23T05:50:19 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/26690 <pre>I'll try to keep this short so you can get to reading the requirements. I have just posted the product requirements for Kilimanjaro Basecamp at: https://wiki.mozilla.org/Kilimanjaro/Basecamp Note: There may be some change as there are outstanding questions, specifically in relation to carrier billing. However, this is pretty close to a final put from the product team. Want a gentle introduction to Basecamp? I wrote about that last week - see Hiking to Basecamp in the dev.planning archive: https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.planning/8yhzstxwz0k Comments, questions, suggestions, thought dumps to dev.planning please. Lawrence </pre> Lawrence Mandel 2012-05-22T22:06:24 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/26689 <pre>The times we currently have just aren't working. Putting together triage page and we will pick new times and send out notices. Cheers, Sheila </pre> Sheila Mooney 2012-05-22T18:10:19 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/26688 <pre>Thought this being our second off week for Snappy that a reminder was in order. In keeping with our now bi-weekly Snappy schedule, this is a Snappy off week. Status will still be collected and communicated. Please add you status to the etherpad by EOD Thursday, May 24, 2012. https://etherpad.mozilla.org/snappy Lawrence </pre> Lawrence Mandel 2012-05-22T16:56:44 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/26687 <pre> Updated, thanks for pointing that out. </pre> Lukas Blakk 2012-05-22T16:40:41 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/26686 <pre>Over the weekend an issue occurred with the BMO database which resulted in duplication of dependencies and bug history [Bug 756790]. The dependency issue may have resulted in "Depends On" and "Blocks" values being removed while updating a bug. This issue should now be resolved, however dependencies may need to be manually restored to some bugs (most occurrences have already been fixed soon after they occurred). The cleanup of the activity table is more complicated, you may see some bugs completely lacking any history until we can complete the data correction [Bug 757024]. </pre> Byron Jones 2012-05-22T14:40:34 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.mozilla.devel.seamonkey