Re: [Advance warning] Session Restore is changing, will break add-ons
On 5/23/13 8:45 AM, Tim Taubert wrote: I talked to Gavin yesterday and we think the best approach would be to back out the Session Restore changes for now as they don't provide a real benefit other than code cleanup (and don't block any other work). The plan would then be to re-land them *with* a kill switch in the same cycle that brings Australis - so we would need to prepare and keep those patches ready. The reasoning is that we indeed will break different add-ons than Australis but at least there will only be one release with a couple of add-ons breaking instead of two in a row. Yes, I believe that's best. For bug 838577 we will probably need to maintain a shadow tree as Johnathan mentioned. I would suggest we talk to Ehsan as he has experience in doing this successfully. I'll get started on that. Expect the complicated patch to become more complicated :) Cheers, David - Tim -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [RFC] Modules for workers
Well, if we do not want the main thread to collapse under its weight, we have to move code off the main thread and to encourage add-ons to do likewise. I'm not sure I see an alternative here. Cheers, David On 5/24/13 1:12 AM, Jonas Sicking wrote: My main concern is that Workers created by Gecko are really expensive memory-wise. See the thread started by Justin Lebar titled Rethinking the amount of system JS we use in Gecko on B2G. The short of it is that each Worker requires a separate JS Runtime and we simply haven't optimize runtimes for having lots of them. This is especially a problem for B2G where we are very short on memory and where we are running multiple copies of Gecko. I would expect the same thing to be an issue on Firefox for Android, though maybe less so since we're generally running on higher-end hardware with more memory. So creating Workers from frontend desktop-only code seems fine. But it's something that would worry me if we start doing in cross platform Gecko code. / Jonas -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: We should drop MathML
On Mon, May 6, 2013 at 1:52 AM, Benoit Jacob jacob.benoi...@gmail.comwrote: 2013/5/5 Robert O'Callahan rob...@ocallahan.org One other thing: EPUB publishers are screaming for good math support for textbooks (and currently that means they want MathML). They're mostly Webkit-based, and maybe we don't care about them, but there you are. Given that TeX is already the standard in scientific publishing, I would find it very surprising if they complained about a TeX-based or TeX-like format ! TeX is a programming language and, in practice, running the program results in a rigid PDF. For the Web, we need something that can dynamically reflow to different viewports and integrate with CSS layout. MathJax or Web Components involve the publisher sending a program along with a supposedly declarative representation, so as a whole, it's again like sending a program, because you have to run the program to be sure about what the declarative input really results. EPUB publishers want something that is declarative and reflows to viewport width. Presentation MathML is that and it doesn't make sense to start over. These days, it's fashionable to rely on JavaScript and to treat downloadable EPUB files as an anachronism in an always-online world, but there's still value in being able to represent content in a way that can be reflown, edited, copied and pasted instead of only being rendered by a program supplied by the publisher. After all, we have all this CSS stuff for non-mathematical text instead of each site sending over an emscripten-compiled typesetter that paints the image of text onto canvas. Although math doesn't have the same mass-market appeal as text in general, math is pretty important for humanity, so I think it makes sense to keep the way to handle mathematical text in a way that's analogous with other text in browsers (declarative, reflowable, has a DOM) and endeavor to get Wikipedia to actually use it by default so that Chrome and IE would have compatibility pressure from a ridiculously mainstream site even if not from its most mainstream articles. (Compared to music and flowcharts, math has a greater need to integrate with line layout instead of working as an image-like region, so it makes less sense to use SVG. As for chemistry, presentation MathML probably serves chemistry pretty well, too.) -- Henri Sivonen hsivo...@hsivonen.fi ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Code Review Session
On 5/23/2013 5:32 AM, Scott Johnson wrote: Members of dev-platform: As part of the Web Rendering work-week in Taiwan, we had a discussion of the process of code review, graciously led by roc. If you were unable to attend, or were able to attend and would like to review the proceedings, notes are available here: https://etherpad.mozilla.org/TaiwanWorkWeekCodeReview Special thanks to Anne van Kesteren and Daniel Holbert for assisting me in the note-taking when my laptop battery died. I'll reply here, but I'm not sure if there are other places we should post this information: * patch size/patch contents included in review email: this was mostly fixed in bug 689601 * Automated tools: mhoye has identified lack of automated review as one of our biggest blockers to getting more mentors involved and having successful mentoring for new volunteers. It turns out that nobody wants to mentor bugs when most of the interaction involves please fix this whitespace/style/etc. cc'ing him so he can provide more details. * I think we should experiment (again) with real pull-request integration into bugzilla. I've been looking at gerrit, which shows some promise but may be very difficult to integrate. http://julien.danjou.info/blog/2013/rant-about-github-pull-request-workflow-implementation resonates strongly with me personally, but I don't know if the actual tool will be good enough to use without major modifications. There are certainly some valuable things we could do with pull requests, such as direct integration with the tryserver and automatic pushing after review. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
No Rendering meeting this Monday
There will be no rendering meeting this coming Monday (May 27), as many people will be recovering from jet lag from the Taipei work week. The next rendering meeting will be announced by Milan, probably for the week after. Benoit ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Code Review Session
Sounds like we're talking about code review. But I want to qualify integration into bugzilla: I explicitly do not want a tool that is tightly coupled to bugzilla. In fact, I want a tool that has as little to do with bugzilla as feasible. I'm a contributor to the Review Board project[1], which is not coupled with Bugzilla whatsoever. It also has an extension called ReviewBot[2], which can run patches through static analysis or automated tests, and inject the results automatically into the review request as a ReviewBot review. It has support for teams / review groups, and multiple repositories (both private/public Github repos, as well as self-hosted hg repos). I'm happy to answer questions about Review Board if anybody has any. If we're talking about considering new review tools, I think Review Board should be on the list of things to try. Here are some pretty pictures: http://www.reviewboard.org/screenshots/ -Mike [1]: http://www.reviewboard.org/ [2]: https://github.com/smacleod/ReviewBot On 24/05/2013 10:50 AM, Justin Lebar wrote: * I think we should experiment (again) with real pull-request integration into bugzilla. I'm totally in favor of better tools and real pull requests, and of course the PRs need to be linked to bugzilla /somehow/. But I want to qualify integration into bugzilla: I explicitly do not want a tool that is tightly coupled to bugzilla. In fact, I want a tool that has as little to do with bugzilla as feasible. I mean no disrespect to our bugzilla maintainers, who have an impossible and largely thankless job, but bugzilla has so much baggage from the '90s, my experience is that it ruins everything it touches. Consider for example how much better harthur's fileit and dashboard tools [1] [2] are than bugzilla's built-in equivalents. We shouldn't conflate owning the PR data with integrating the PR tool into bugzilla. If we do, we risk ending up with yet another crappy non-solution to a real problem (see bugzilla interdiff, splinter integration, and so on). -Justin [1] http://harthur.github.com/fileit/ [2] http://harthur.github.io/bugzilla-todos/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Code Review Session
On Fri, May 24, 2013 at 10:50 PM, Justin Lebar justin.le...@gmail.comwrote: If we do, we risk ending up with yet another crappy non-solution to a real problem (see bugzilla interdiff, splinter integration, and so on). I think that's quite unfair to the people who integrated Splinter. It's not everything I want, but I like it a lot better than what we had before. Rob -- q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Code Review Session
On Fri, May 24, 2013 at 08:40:29AM -0700, Michael Hoye wrote: - Original Message - From: Benjamin Smedberg benja...@smedbergs.us To: Scott Johnson sjohn...@mozilla.com Cc: dev-platform@lists.mozilla.org, Michael Hoye mh...@mozilla.com * Automated tools: mhoye has identified lack of automated review as one of our biggest blockers to getting more mentors involved and having successful mentoring for new volunteers. It turns out that nobody wants to mentor bugs when most of the interaction involves please fix this whitespace/style/etc. cc'ing him so he can provide more details. Yeah, so, about that. Having spoken to a handful of developers, this is #2 on the List Of Things People Dislike About Mentoring, having to go back-and-forth with a contributor about style conventions and whitespace. In short, everyone hates it, everyone understands that this should be completely and utterly automated. A question I'm trying to clear up for myself is: I understand that clang-format is somehow inadequate to our needs, but I see that there's an explicit clang-format -style=Mozilla option that claims to be doing the right Mozilla thing. So, I'm hoping somebody can give me a clearer idea of how clang-format is broken. clang-format unfortunately only deals with whitespaces. It does have neat formatting with them, but it's limited to that. Unfortunately, coding style is also about naming conventions (camel case, hungarian notation, etc.), braces positions and presence, etc. Triple-unfortunately, we have an almost infinite number of combinations of those. CELS is a tool that can help with these. https://bitbucket.org/PEConn/cels Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Code Review Session
On 2013-05-24 11:46 AM, Benoit Girard wrote: On Fri, May 24, 2013 at 10:30 AM, Benjamin Smedberg benja...@smedbergs.uswrote: * Automated tools: mhoye has identified lack of automated review as one of our biggest blockers to getting more mentors involved and having successful mentoring for new volunteers. It turns out that nobody wants to mentor bugs when most of the interaction involves please fix this whitespace/style/etc. cc'ing him so he can provide more details. I've got some patches that import webkit's check-style script to check the style[1]. It just runs regex rather then doing a real parse of the code but importing it turns out to be a low effort/high reward. I've already started working on a robot to post to bugzilla. Perhaps later we can replace it with a more intelligent tool. Another option is to use clang-format, which can lexically parse diff files. Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: מדוע בישראל לא מרוויחים
שלום. בהמשך לחשיפת מחקרנו בערוץ 10 – 94 אחוז מהעסקים בישראל לא מרוויחים מספיק במהלך 13 השנים האחרונות, לאחר שבחנו מעל 12 אלף עסקים מכל הסוגים בישראל ובארצות-הברית, גילינו שעסקים רבים בישראל יכולים היו לעמוד על רווחים כספיים גבוהים בהרבה, אם לא מספר טעויות שנעשות על ידם. בחג האחרון הוקצו מספר מושבים חינם לסדנא מתנה לבעלי העסקים בישראל, בה יפורטו כל הטעויות שבגללן רוב בתי העסק בישראל לא מרוויחים מספיק. המרצה הוא מחבר רב המכר האם שווה להיות עצמאי?, יועץ בינלאומי בעל ניסיון עצום בהגדלת רווחים של עסקים תוך זמן קצר. הסדנא תתקיים ביום שני, 3 ליוני, 17:30 עד 20:00, מול גני-התערוכה. נותרו מספר כרטיסים בודדים. הכניסה לבעלי עסקים ובני משפחותיהם בלבד. הסדנה היא במימון אמריקאי מלא. אין צורך בתשלום, אך מותנית בהרשמה מראש לקבלת כרטיס כניסה נא להשיב למייל זה עם הפרטים הבאים: שם החברה / העסק: שם בעל העסק: טלפון נייד : פקס: אי-מייל : בברכה, ראש צוות סניף ארהב. *מספר המקומות מוגבל – נא לא להגיע לפני קבלת אישור מהמשרד בארץ. המכון לאבחון עסקי Ventura Blvd, Woodland, California טלפון סניף ישראל (24 שעות ביממה): 03-7300852 dev-platform@lists.mozilla.org - עסק רשום. משלוח הזמנה זו נעשה באמצעות ובחסות Business Diagnosis Institute - לוס-אנג'לס, ארהב. ההזמנה נשלחה כשירות לציבור. אין לראות בה פרסומת לשירות כלשהו בתשלום. אם ברצונך לקבל מידע בפקס או מייל לגבי שירותים בתשלום, נא לשלוח מכתב זה במייל חוזר. אם המכתב הגיע אליך בטעות, או שברצונך לא לקבל מכתבים נוספים נא לשלוח דף זה חזרה עם המילה מחק בשורת הנושא. . נשלח ל dev-platform@lists.mozilla.org ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: new build-time defines for controlling when features ship
One thing I forgot to mention explicitly but that is worth following up on: we should generally be striving to get rid of code that is enabled/disabled based on the value of MOZ_UPDATE_CHANNEL. If you are responsible for any such code, please file bugs to switch them to using these build defines, wherever possible (and where not possible, file a bug to investigate adding a define that better addresses the specific use case). Bug 875342 is one such example. Gavin On Thu, May 16, 2013 at 5:04 PM, Gavin Sharp ga...@gavinsharp.com wrote: Bug 853071 landed in the Firefox 23 cycle, adding some defines that make it possible to control when in the release cycle code is built. I've described the various defines here: https://wiki.mozilla.org/Platform/Channel-specific_build_defines To recap: NIGHTLY_BUILD is defined when milestone.txt contains a1, i.e. for mozilla-central builds. RELEASE_BUILD is defined when milestone.txt does not contain a, i.e. for builds off of mozilla-beta or mozilla-release. EARLY_BETA_OR_EARLIER is defined depending on the corresponding value in build/defines.sh. This file is managed manually by the release management team, with the variable being cleared once we're past the early beta point in the release cycle. All of these defines are both AC_DEFINE (preprocessors) and AC_SUBSTed (autoconf/makefiles). (RELEASE_BUILD existed previously, but was only defined in pref files. It's now global.) Gavin ___ firefox-dev mailing list firefox-...@mozilla.org https://mail.mozilla.org/listinfo/firefox-dev ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: new build-time defines for controlling when features ship
I've described the various defines here: https://wiki.mozilla.org/**Platform/Channel-specific_**build_defineshttps://wiki.mozilla.org/Platform/Channel-specific_build_defines My understanding of this is that we were going to limit use of all of these options to control preference-flipping. In particular I'm worried about build bustage that is only discovered at channel-uplift time. As mentioned in the firefox-dev thread, I don't expect this to be a serious problem in practice, and I don't think preference flipping is sufficient to cover all the use cases (some things can't be easily/cleanly pref-controlled). If I'm wrong about that we can revisit automated solutions to detecting bustage earlier. And we need this on the Android side too. That code is not easily handled via preference flipping since the code is native Java. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Code Review Session
On 05/24/2013 11:05 AM, Mike Conley wrote: Sounds like we're talking about code review. But I want to qualify integration into bugzilla: I explicitly do not want a tool that is tightly coupled to bugzilla. In fact, I want a tool that has as little to do with bugzilla as feasible. I'm a contributor to the Review Board project[1], which is not coupled with Bugzilla whatsoever. Noting that although it's not coupled, Review Board makes it very possible to do things that make it an abandon-able solution. Back in 2009 (before there was extension/plugin support) I modified review board so it could pull your review queue out of bugzilla and automatically generate reviews. To address long-term archival needs, I added export functionality that formatted the review as ASCII text that could be copied and pasted into bugzilla. Here's an example excerpt from my blog post at http://www.visophyte.org/blog/2009/06/20/review-board-and-bugzilla-reviews-take-2/: === on file: mailnews/base/src/nsMessenger.cpp line 635 // if we have a mailbox:// url that points to an .eml file, we have to read // the file size as well what a pretty comment on file: mailnews/base/src/nsMessenger.cpp line 642 NS_ENSURE_SUCCESS(rv, rv); please rename rv ARR-VEE === I personally worry about introducing another piece into the existing bugzilla/github interaction, but even 4 years ago, review board had a reviewing experience that is still ahead of both splinter and github. (Although I do have high hopes that github will improve their review experience.) Specifically: - Side-by-side diff (github-only problem) - Syntax highlighted code based on syntax highlighting the entire file, so it's not just a line-centric/keyword centric highlighting. - Expandable context! Don't get stuck with only 3 or 8 lines of context. Expand to see the whole file! - Detects when code is just moved around. This came towards the tail end of my use of it, but it was a killer feature for refactored code. No trying to play the game of match up the added hunk and the removed hunk. It figured it out for you, greatly reducing complexity. Also nice (versus github): - Your review isn't published until you push a button, allowing you to make persistent notes to yourself that you can later remove when you see they aren't an issue without bothering anyone else. This also saves you from proactive people fixing things and pushing fixes as you type them and causing massive confusion. - Reviews don't get nuked by rebases Right now, for tricky reviews, I find myself having to checkout the code locally then use git difftool with the meld 3-way merge tool to diff the branch against its base in order to get syntax-highlighted side-by-side diff with full context and smart intra-line diffing. Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
