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://comments.gmane.org/gmane.comp.mozilla.devel.seamonkey/26713 <pre>Agenda: https://wiki.mozilla.org/SeaMonkey/StatusMeetings/2012-05-29 * 29 May, 12:00 UTC, 8am Eastern, 1pm UK, 2pm Central Europe * Other timezones: &lt;http://www.timeanddate.com/worldclock/fixedtime.html?day=29&amp;month=5&amp;year=2012&amp;hour=13&amp;min=0&amp;sec=0&amp;p1=0&gt; * IRC channel #seamonkey - irc://irc.mozilla.org/seamonkey Hi everybody, We're doing another instance of our biweekly SeaMonkey Status meetings on IRC. Please add agenda items we should discuss, we're trying to get a good view there where the SeaMonkey project is right now, what the progress is compared to last time and where we are headed. Main agenda items: - Release Train - Extensions Compatibility Tracking - Feature List, 2.9 and later - Roundtable If you can't participate, please remember to fill in all the info you can tell us in the wiki. Greetings, Jens </pre> Jens Hatlak 2012-05-26T08:26:46 http://comments.gmane.org/gmane.comp.mozilla.devel.seamonkey/26712 <pre>Hi, The Gfx meeting next monday is cancelled primarily because I forgot to announce it before tonight, and also because we've had meetings the past two weeks and the last one we didn't have that much to discuss (with one of us, who shall remain nameless, repeatedly asking "so, anything else to discuss" three minutes into the meeting) and also, just to add another excuse, as next Monday is Memorial Day in the US. We'll most probably have a Gfx meeting the Monday after, June 4th. Cheers, Benoit </pre> Benoit Jacob 2012-05-26T03:00:37 http://comments.gmane.org/gmane.comp.mozilla.devel.seamonkey/26711 <pre>Weekly on Thursday at 0800 PDT / 1700 CET / 2300 CST Vidyo: Dietrich's room (until we get the B2G room set up) https://etherpad.mozilla.org/gaia-triage This week we'll cover the unclassified bugs, then pass through QA-blocked and platform-blocked. </pre> Dietrich Ayala 2012-05-26T00:06:02 http://comments.gmane.org/gmane.comp.mozilla.devel.seamonkey/26710 <pre>Weekly on Tuesday at 1300 PDT / 2200 CET / 0400 CST Vidyo: Dietrich's room (until we get the B2G room set up) https://etherpad.mozilla.org/b2g-triage This week we're kicking off with a romp through as many of the platform bugs as we can get to: Boot2Gecko, DOM, Graphics and more. </pre> Dietrich Ayala 2012-05-26T00:01:53 http://comments.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://comments.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://comments.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://comments.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://comments.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://comments.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://comments.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://comments.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://comments.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://comments.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://comments.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 http://comments.gmane.org/gmane.comp.mozilla.devel.seamonkey/26684 <pre>Howdy y'all, We will be holding our regular weekly product coordination meeting Wednesday at 11am PT. The purpose of this meeting is to get answers to product coordination questions, share information and make sure our efforts are in sync for upcoming releases. Agenda, notes and dial in information here: https://wiki.mozilla.org/Firefox/Planning/2012-05-23 * Please add product details/highlights/notices to the relevant sections * Ask questions - you'll get answers! # Mozilla Mountain View: Warp Core, 3rd floor # 650-903-0800 or 650-215-1282 x92 Conf# 95312 (US/INTL) # 1-800-707-2533 (pin 369) Conf# 95312 (US) # Vidyo Room: Warp Core # Vidyo Guest URL: https://v.mozilla.com/flex.html?roomdirect.html&amp;key=UK1zyrd7Vhym (please mute) # irc.mozilla.org #planning for backchannel --- Johnathan Nightingale Sr. Director of Firefox Engineering &lt; at &gt;johnath </pre> Johnathan Nightingale 2012-05-22T14:25:00 http://comments.gmane.org/gmane.comp.mozilla.devel.seamonkey/26683 <pre>Meeting Details: * Agenda: https://wiki.mozilla.org/Platform/2012-05-22 * Tue, May 22, 11:00 am Pacific * Warp Core Vidyo Room * Vidyo Phone# 650-903-0800 x92 Conf#95312 (US/INTL) * 1-800-707-2533 (pin 369) Conf# 95312 (US) * join irc.mozilla.org #planning for back channel -JP </pre> JP Rosevear 2012-05-22T13:31:45 http://comments.gmane.org/gmane.comp.mozilla.devel.seamonkey/26682 <pre>We are going to spend 1/2 hr looking at the k9o nom queue. We are going to stick with the Tuesday 11:30am time even though it conflicts with the mobile triage since attendance has been good after the 11:30am engineering call. The Friday meeting time (and maybe day) will change to accommodate participation from the mobile team. http://bit.ly/IKpol6 Details: * Mozilla Mountain View: Warp Core conf room, 3rd floor * 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 </pre> Sheila Mooney 2012-05-22T06:21:47 http://comments.gmane.org/gmane.comp.mozilla.devel.seamonkey/26681 <pre>Join us for the B2G Weekly Meeting! Time: Tuesdays 1700 PDT / 0200 CET / 0800 CST Dial-in: +1 650 903 0800 x92 Conf 434# +1 416 848 3114 x92 Conf 434# +1 800 707 2533 (pin 369) Conf 434# (toll free, Skype) (No Vidyo) Notes during the meeting are captured at https://etherpad.mozilla.org/b2g-meeting-notes and later transferred to B2G/Meeting Notes. Team members please update the etherpad with your status! </pre> Dietrich Ayala 2012-05-22T06:19:09 http://comments.gmane.org/gmane.comp.mozilla.devel.seamonkey/26680 <pre>Gaia Weekly Meeting Time: Tuesdays 0900 PDT / 1700 CET / 0000 CST Dial-in: +1 650 903 0800 x92 Conf 434# +1 416 848 3114 x92 Conf 434# +1 800 707 2533 (pin 369) Conf 434# (toll free, Skype) Vidyo: MTV 2J-JK Notes during the meeting are captured https://etherpad.mozilla.org/gaia-meeting-notes and later transferred to Gaia/Meeting Notes. Team members please update your status on the etherpad! </pre> Dietrich Ayala 2012-05-22T06:05:12 http://comments.gmane.org/gmane.comp.mozilla.devel.seamonkey/26679 <pre>Join us! In person: SFO-7R ( at Mozilla's San Francisco office ) Vidyo: https://v.mozilla.com/flex.html?roomdirect.html&amp;key=W1xz8rcslKbR Backchannel: #jetpack IRC channel Alternative Call-in: 1-800-707-2533 - conference room 99449 (tell us on IRC if you need this option) Agenda: https://wiki.mozilla.org/Jetpack/Weekly_Meeting/2012-5-21#Agenda </pre> Jeff Griffiths 2012-05-22T04:02:16 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.mozilla.devel.seamonkey