Re: Phabricator Update, July 2017
lets all try I'm > On 14 Jul 2017, at 13:48, Jim Blandy wrote: > > Yeah, this is kind of the opposite of "No New Rationale". > > https://air.mozilla.org/friday-plenary-rust-and-the-community/ > > >> On Thu, Jul 13, 2017 at 2:49 PM, David Anderson wrote: >> >>> On Thursday, July 13, 2017 at 1:38:18 PM UTC-7, Joe Hildebrand wrote: >>> I'm responding at the top of the thread here so that I'm not singling >> out any particular response. >>> >>> We didn't make clear in this process how much work Mark and his team did >> ahead of the decision to gather feedback from senior engineers on both >> Selena and my teams, and how deeply committed the directors have been in >> their support of this change. >>> >>> Seeing a need for more modern patch reviewing at Mozilla, Laura >> Thomson's team did an independent analysis of the most popular tools >> available on the market today. Working with the NSS team to pilot their >> selected tool, they found that Phabricator is a good fit for our >> development approach (coincidentally a good enough fit that the Graphics >> team was also piloting Phabricator in parallel). After getting the support >> of the Engineering directors, they gathered feedback from senior engineers >> and managers on the suggested approach, and tweaked dates and features to >> match up with our release cycles more appropriately. >> >> The problem is this hasn't been transparent. It was announced as an edict, >> and I don't remember seeing any public discussion beforehand. If senior >> engineers were consulted, it wasn't many of them - and the only person I >> know who was, was consulted after the decision was made. >> >> I've contributed thousands of patches over many years and haven't really >> seen an explanation of how this change will make my development process >> easier. Maybe it will, or maybe it won't. It probably won't be a big deal >> because this kind of tooling is not really what makes development hard. I >> don't spend most of my day figuring out how to get a changeset from one >> place to another. >> >> The fact is that no one really asked us beforehand, "What would make >> development easier?" We're just being told that Phabricator will. That's >> why people are skeptical. >> ___ >> 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Phabricator Update, July 2017
On 7/14/17 1:31 AM, Jim Blandy wrote: But keeping all the comments in one thread is a mixed blessing, too Absolutely. I guess what I'm saying is we should try to have some guidelines for when it's appropriate to take the discussion back to the bug instead of continuing it in the review... -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Phabricator Update, July 2017
Yeah, this is kind of the opposite of "No New Rationale". https://air.mozilla.org/friday-plenary-rust-and-the-community/ On Thu, Jul 13, 2017 at 2:49 PM, David Anderson wrote: > On Thursday, July 13, 2017 at 1:38:18 PM UTC-7, Joe Hildebrand wrote: > > I'm responding at the top of the thread here so that I'm not singling > out any particular response. > > > > We didn't make clear in this process how much work Mark and his team did > ahead of the decision to gather feedback from senior engineers on both > Selena and my teams, and how deeply committed the directors have been in > their support of this change. > > > > Seeing a need for more modern patch reviewing at Mozilla, Laura > Thomson's team did an independent analysis of the most popular tools > available on the market today. Working with the NSS team to pilot their > selected tool, they found that Phabricator is a good fit for our > development approach (coincidentally a good enough fit that the Graphics > team was also piloting Phabricator in parallel). After getting the support > of the Engineering directors, they gathered feedback from senior engineers > and managers on the suggested approach, and tweaked dates and features to > match up with our release cycles more appropriately. > > The problem is this hasn't been transparent. It was announced as an edict, > and I don't remember seeing any public discussion beforehand. If senior > engineers were consulted, it wasn't many of them - and the only person I > know who was, was consulted after the decision was made. > > I've contributed thousands of patches over many years and haven't really > seen an explanation of how this change will make my development process > easier. Maybe it will, or maybe it won't. It probably won't be a big deal > because this kind of tooling is not really what makes development hard. I > don't spend most of my day figuring out how to get a changeset from one > place to another. > > The fact is that no one really asked us beforehand, "What would make > development easier?" We're just being told that Phabricator will. That's > why people are skeptical. > ___ > 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: Phabricator Update, July 2017
Many people seem to be asking, essentially: What will happen to old bugs? I'm trying to follow the discussion, and I'm not clear on this myself. For example, "Splinter will be turned off." For commenting and reviewing, okay, understood. What about viewing patches on old bugs? Yes, Phabricator will segregate review comments and general discussion. But keeping all the comments in one thread is a mixed blessing, too; for example, check out bug 1271650 and try to tell me what the status of each patch is. "Well, those patches should be split across several bugs." Okay, but that fragments the conversation too. There's an inherent tension here, and Ye Olde Bugzilla Patch Review Process is more of a lovingly polished turd than a good solution. On Thu, Jul 13, 2017 at 8:39 PM, Boris Zbarsky wrote: > On 7/13/17 9:04 PM, Mark Côté wrote: > >> It is also what newer systems >> do today (e.g. GitHub and the full Phabricator suite) >> > > I should note that with GitHub what this means is that you get discussion > on the PR that should have gone in the issue, with the result that people > following the issue don't see half the relevant discussion. In particular, > it's common to go off from "reviewing this line of code" to "raising > questions about what the desired behavior is", which is squarely back in > issue-land, not code-review land. > > Unfortunately, I don't know how to solve that problem without designating > a "central point where all discussion happens" and ensuring that anything > outside it is mirrored there... > > -Boris > > ___ > 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: Phabricator Update, July 2017
On 7/13/17 9:04 PM, Mark Côté wrote: It is also what newer systems do today (e.g. GitHub and the full Phabricator suite) I should note that with GitHub what this means is that you get discussion on the PR that should have gone in the issue, with the result that people following the issue don't see half the relevant discussion. In particular, it's common to go off from "reviewing this line of code" to "raising questions about what the desired behavior is", which is squarely back in issue-land, not code-review land. Unfortunately, I don't know how to solve that problem without designating a "central point where all discussion happens" and ensuring that anything outside it is mirrored there... -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Phabricator Update, July 2017
On Thu, Jul 13, 2017 at 6:04 PM, Mark Côté wrote: > On 2017-07-13 3:54 PM, Randell Jesup wrote: > >> On Wed, Jul 12, 2017 at 11:27 AM, Byron Jones wrote: >>> >>> But indeed having also the patches in bugzilla would be good. > > no, it would be bad for patches to be duplicated into bugzilla. we're moving from bugzilla/mozreview to phabricator for code review, duplicating phabricate reviews back into the old systems seems like a step backwards (and i'm not even sure what the value is of doing so). >>> >>> I find this a strange argument. We don't know how successful >>> phrabricator >>> is going to be. The last attempt to switch review tools seems to be >>> getting killed. I think its somewhat reasonable to be skeptical of >>> further >>> review tool changes. >>> >> >> I quite agree... And I hate the idea of having the data spread across >> systems (which I also disliked in MozReview, which I tried and it ended >> up being really bad for some aspects of my ability to land patches). >> > > Mirroring comments from Phabricator to BMO is even more confusing, as we > end up with forked discussions, where some people reply only on BMO. This > happens regularly with MozReview, as a quick survey of recently fixed bugs > shows. Keeping code review in one place, loosely coupled to issue > tracking, improves readability of bugs by keeping discussion of issues > separate from specific solutions. It is also what newer systems do today > (e.g. GitHub and the full Phabricator suite), which I mention not as a > reason in and of itself but to note precedent. The plan is to move to a > separate, more modern, and more powerful code-review tool. Forked > discussions means that the bugs will always have to be consulted for code > reviews to progress, which undermines the utility of the code-review tool > itself. Loose coupling also frees us to try experiments like patches > without bugs, which has been discussed many times but has been technically > blocked from implementation. > > That said, lightweight linkages between issues and code review are very > useful. We're doing some of that, and we're open to iterating more there. > > We've been asked to be bold and innovate all across Mozilla, to try new > things and see if they work. For a long time, Mozillians have discussed > modernized workflows, with new tools that also open more avenues to > automation, but such things have been rarely attempted, and even then in a > disorganized fashion. We're finally at a time when we have the ability and > support to forge ahead, and that's what we're doing. > This. As someone who worked on MozReview, I can say unequivocally that one of the hardest parts - and I dare say the thing that held MozReview back the most - was the tight coupling with Bugzilla and the confusion and complexity that arose from it. When we deployed MozReview, we intentionally tried to not rock the boat too hard: we wanted it to be an extension of the Bugzilla-centric workflow that everyone was familiar with. Was there some boat rocking, yes: that's the nature of change. But we went out of our way to accommodate familiar workflows and tried to find the right balance between old and new. This resulted in obvious awkwardness, like trying to map ReviewBoard's "Ship It" field to Bugzilla's complicated review flag mechanism. Does a review that doesn't grant "Ship It" clear the r? flag or leave it? What happens when someone grants "Ship It" but they don't have permissions to leave review flags in Bugzilla? How do you convey r-? What about feedback flags? What happens when someone changes a review flag in Bugzilla? Then you have other awkwardness, like when you mirror the review comment to Bugzilla and it loses rich text formatting. Or someone replies to a MozReview comment on Bugzilla and you can't see that reply on MozReview. Do you disable replying to comments mirrored from MozReview? That's annoying. Do you disable the mirroring then? That's annoying too! Bi-directional sync? No way! (If you've ever implemented bi-directional sync you'll know why.) You just can't win. The usability issues stemming from trying to overlay ReviewBoard's and Bugzilla's models of how the world worked were obvious and frustrating. It took months to years to iron things out. And we arguably never got it right. Then there were technical issues. When you did things like post a series of commits to review on MozReview, this was done so as an atomic operation via a database transaction. It either worked or it didn't. But we had to mirror those reviews to Bugzilla. Bugzilla didn't have an API to atomically create multiple attachments/reviews. So not only was the publishing to Bugzilla slow because of multiple HTTP requests, but it was also non-atomic. When Bugzilla randomly failed (all HTTP requests randomly fail: it is a property of networks), the review series in Bugzilla was sometimes left in an inconsistent state because it wasn't obviou
Re: Phabricator Update, July 2017
On 2017-07-13 3:54 PM, Randell Jesup wrote: On Wed, Jul 12, 2017 at 11:27 AM, Byron Jones wrote: But indeed having also the patches in bugzilla would be good. no, it would be bad for patches to be duplicated into bugzilla. we're moving from bugzilla/mozreview to phabricator for code review, duplicating phabricate reviews back into the old systems seems like a step backwards (and i'm not even sure what the value is of doing so). I find this a strange argument. We don't know how successful phrabricator is going to be. The last attempt to switch review tools seems to be getting killed. I think its somewhat reasonable to be skeptical of further review tool changes. I quite agree... And I hate the idea of having the data spread across systems (which I also disliked in MozReview, which I tried and it ended up being really bad for some aspects of my ability to land patches). Mirroring comments from Phabricator to BMO is even more confusing, as we end up with forked discussions, where some people reply only on BMO. This happens regularly with MozReview, as a quick survey of recently fixed bugs shows. Keeping code review in one place, loosely coupled to issue tracking, improves readability of bugs by keeping discussion of issues separate from specific solutions. It is also what newer systems do today (e.g. GitHub and the full Phabricator suite), which I mention not as a reason in and of itself but to note precedent. The plan is to move to a separate, more modern, and more powerful code-review tool. Forked discussions means that the bugs will always have to be consulted for code reviews to progress, which undermines the utility of the code-review tool itself. Loose coupling also frees us to try experiments like patches without bugs, which has been discussed many times but has been technically blocked from implementation. That said, lightweight linkages between issues and code review are very useful. We're doing some of that, and we're open to iterating more there. We've been asked to be bold and innovate all across Mozilla, to try new things and see if they work. For a long time, Mozillians have discussed modernized workflows, with new tools that also open more avenues to automation, but such things have been rarely attempted, and even then in a disorganized fashion. We're finally at a time when we have the ability and support to forge ahead, and that's what we're doing. Mark ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Merge Day changes coming up soon
Hi there, Release management and release engineering have changed the dates for the next release cycle's merge day. Firefox 56 will move to mozilla-beta, and Firefox 57 will become Nightly, on August 2 (rather than August 7). You should still be able to check in patches to mozilla-central normally. For anything that you need to land for 56 beta 1, between August 2 and 7, please request uplift to beta. We'll still be doing the beta 1 build on Monday, August 7 for release on Tuesday, August 8. This should give much more time for sheriffs and releng to fix tests and resolve merge related issues. It will limit last minute churn for the last 5 days before the beta release, while still keeping m-i and m-c open. I think it will give us an improved chance of shipping beta 1 on schedule. We're also planning on repeating this pattern for the 57 move to beta in September, so 57 will move to mozilla-beta, and 58 to m-c, to become Nightly, on Sept. 20th instead of Sept. 25. Thanks to Aki for this plan, and to the l10n team, release duty folks, relman, release-drivers, and the comms team for feedback on how to make it work. If you have questions or other feedback, please let me know. Best, Liz -- Liz Henry (:lizzard) Firefox Release Manager lhe...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: More Rust code
On Tue, Jul 11, 2017 at 11:03 AM, Nicholas Nethercote < n.netherc...@gmail.com> wrote: > > >> The first thing comes to my mind is crash reports. It currently doesn't >> always include useful panic message from Rust, see for example [1] and [2]. >> > > I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1379857 for this. > It's blocking https://bugzilla.mozilla.org/show_bug.cgi?id=1348896, which > is the Rust crash tracking bug. > jryans just landed a fix for bug 1379857. Turns out that Rust panic messages weren't being captured by crash reports in content processes. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Phabricator Update, July 2017
On Thursday, July 13, 2017 at 1:38:18 PM UTC-7, Joe Hildebrand wrote: > I'm responding at the top of the thread here so that I'm not singling out any > particular response. > > We didn't make clear in this process how much work Mark and his team did > ahead of the decision to gather feedback from senior engineers on both Selena > and my teams, and how deeply committed the directors have been in their > support of this change. > > Seeing a need for more modern patch reviewing at Mozilla, Laura Thomson's > team did an independent analysis of the most popular tools available on the > market today. Working with the NSS team to pilot their selected tool, they > found that Phabricator is a good fit for our development approach > (coincidentally a good enough fit that the Graphics team was also piloting > Phabricator in parallel). After getting the support of the Engineering > directors, they gathered feedback from senior engineers and managers on the > suggested approach, and tweaked dates and features to match up with our > release cycles more appropriately. The problem is this hasn't been transparent. It was announced as an edict, and I don't remember seeing any public discussion beforehand. If senior engineers were consulted, it wasn't many of them - and the only person I know who was, was consulted after the decision was made. I've contributed thousands of patches over many years and haven't really seen an explanation of how this change will make my development process easier. Maybe it will, or maybe it won't. It probably won't be a big deal because this kind of tooling is not really what makes development hard. I don't spend most of my day figuring out how to get a changeset from one place to another. The fact is that no one really asked us beforehand, "What would make development easier?" We're just being told that Phabricator will. That's why people are skeptical. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: More Rust code
On Wed, Jul 12, 2017 at 04:06:39PM -0700, Eric Rahm wrote: > Interesting points. > >- *using breakpad* - was the problem that creating wrappers to access >the c/c++ code was too tedious? Could bindgen help with that, if not it >would be interesting gather some details about why it wouldn't work and >file bugs against it. >- *pingsender* - was something like https://hyper.rs/ not around when >you were working on it or is this a case of finding the things you want can >be difficult in rust-land? Either way it might be a good idea for us to put >together a list of "sanctioned" crates for various tasks. Note that pingsender is a small self-contained binary. I'm afraid writing in in rust would make it very much larger. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Phabricator Update, July 2017
I'm responding at the top of the thread here so that I'm not singling out any particular response. We didn't make clear in this process how much work Mark and his team did ahead of the decision to gather feedback from senior engineers on both Selena and my teams, and how deeply committed the directors have been in their support of this change. Seeing a need for more modern patch reviewing at Mozilla, Laura Thomson's team did an independent analysis of the most popular tools available on the market today. Working with the NSS team to pilot their selected tool, they found that Phabricator is a good fit for our development approach (coincidentally a good enough fit that the Graphics team was also piloting Phabricator in parallel). After getting the support of the Engineering directors, they gathered feedback from senior engineers and managers on the suggested approach, and tweaked dates and features to match up with our release cycles more appropriately. Although there may be other risks that weren't identified in our approach, I'm personally satisfied that what we have in front of us is strictly better than where we are today. Of course, we'll have to sand and fill a little bit to perfect the new Phabricator approach, and deal with our transition away from existing systems such as Splinter and MozReview. However, that tweaking would be required no matter what tool we chose, or when we chose to make a change. Therefore, I would appreciate that if you feel the need to further comment on this thread, we focus on what can be done to make this transition successful, rather than appearing to be standing in the way of progress. For example, "I'm concerned about X; I wonder if we could do Y to mitigate that concern?" is a much more powerful approach than "X!" at this point. — Joe Hildebrand > On Jul 11, 2017, at 2:41 PM, Mark Côté wrote: > > Hi all, here's a brief update on the project to deploy and integrate > Phabricator at Mozilla: > > * Development Phabricator instance is up at > https://mozphab.dev.mozaws.net/, authenticated via > bugzilla-dev.allizom.org. > > * Development, read-only UI for Lando (the new automatic-landing > service) has been deployed. > > * Work is proceeding on matching viewing restrictions on Phabricator > revisions (review requests) to associated confidential bugs. > > * Work is proceeding on the internals of Lando to land Phabricator > revisions to the autoland Mercurial branch. > > * Pre-release of Phabricator, without Lando, targeted for mid-August. > > * General release of Phabricator and Lando targeted for late September or > early October. > > * MozReview and Splinter turned off in early December. > > I have a blog post up with many more details: > https://mrcote.info/blog/2017/07/11/phabricator-update/ > > More to come! > > Mark > > ___ > 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: Phabricator Update, July 2017
>On Wed, Jul 12, 2017 at 11:27 AM, Byron Jones wrote: > >> But indeed having also the patches in bugzilla would be good. >>> >> no, it would be bad for patches to be duplicated into bugzilla. we're >> moving from bugzilla/mozreview to phabricator for code review, duplicating >> phabricate reviews back into the old systems seems like a step backwards >> (and i'm not even sure what the value is of doing so). > >I find this a strange argument. We don't know how successful phrabricator >is going to be. The last attempt to switch review tools seems to be >getting killed. I think its somewhat reasonable to be skeptical of further >review tool changes. I quite agree... And I hate the idea of having the data spread across systems (which I also disliked in MozReview, which I tried and it ended up being really bad for some aspects of my ability to land patches). >Also, I have to say the whole phabricator thing has been kind of presented >as a fait accompli. As someone who continues to use splinter on a daily >basis I'm 1) skeptical and 2) kind of unhappy. > >Maybe phabricator will be great, but I'll believe it when I see it. Please >don't force future data and workflow into an as-yet unproven tool. This while sequence strikes me as "Let's launch our new boat, and oh by the way we're going to sink the old boat(s) so no one is tempted to not move to the new boat. And, BTW, we're leaving behind some important things, and we'll think about how we can deal with those sometime, maybe before we launch, maybe later, maybe never." While this may force people onto the new boat, I'm seriously unconvinced this will be better in the short term, or that it won't end up slowing down N*100 developers, either for a while or permanently. And the lack of transparency in developing this plan is also very concerning. IMO -- Randell Jesup, Mozilla Corp remove "news" for personal email ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Phabricator Update, July 2017
>>> To answer the other part of your question, MozReview will be disabled for >>> active use across the board, but it is currently used by a small number of >>> projects. Splinter will be disabled on a per-product basis, as there may be >>> some projects that can't, won't, or shouldn't be migrated to Phabricator. >> >> Splinter is still a nice UI to look at patches already attached to bugs. >> Please don't disable it. > >excellent point; thanks for that feedback. > >instead of disabling splinter for phabricator backed products, we could >make it a read-only patch viewer. I would consider it a massive fail if we disabled at least read-only splinter viewing of patches. As noted before. let's make sure we don't lose things we agreed on as issues. -- Randell Jesup, Mozilla Corp remove "news" for personal email ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
mozilla-central is closed for lack of mac symbols/crash data
Starting with Monday's nightly we've discovered that we're missing mac symbols for the XUL library. Because this makes crash statistics useless, this means that we can't bisect or detect most crash issues on mac. For that reason, I've asked sheriffs to close the tree. This is being tracked in bug 1380381, and is a recurrence of an older issue from bug 1371017 and bug 1301751. Currently these sorts of symbol errors don't fail the build and so we don't notice them very quickly, but that is being tracked in bug 1304042 and I hope we can land that soon to avoid a recurrence of this issue. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: More Rust code
[moving dev-platform and firefox-dev to Bcc] What I've heard in this thread is that we have a few blockers, some pain points and bugs to file regarding more Rust integration with Firefox. Nick -- please ensure those bugs get filed, and a meta-bug entitled "Make the developer experience for Firefox + Rust great". There are some issues that Stylo needs resolved before we ship, and those bugs should probably block a Stylo tracking bug. Once we have that in place, we can work together to prioritize them. Whatever is blocking Stylo would be high priority Rust/tooling work. Also, the Stylo team is considering what performance related work will be the highest priority. We also have significant technical problems to solve regarding integration between C++/Rust/JS components. Bobby raised the issue of our decision making process around where to focus efforts around Rust integration. Ehsan is on vacation this week, so let’s pause this discussion and have a meeting next week between the module peers and those who have been working on the Stylo integration, because they have to most relevant experience. I’ll put that together and report out. -selena ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: More Rust code
On 10.07.2017 12:29, Nicholas Nethercote wrote: Hi folks, Firefox now has multiple Rust components, and it's on track to get a bunch more. See https://wiki.mozilla.org/Oxidation for details. I wonder which of the pressing problems (eg. massing resource wasting, bad performance, horribly complicated build systems, hard to maintain source tree, too much in one application, etc), are actually improved by yet another language. No idea, which fancy features of rust you're so keen on, but most of what I've seen so far, has already been done in ADA (hmm, does rust have domain types and compile-time constraints?) By the way, just in case nobody noticed: recent Debian stable doesn't have rustc (for good reasons, as it's still unstable), so pretty much no chance of recent moz in Debian world (I'd guess the same w/ other stable distros) - limited to bleeding-edge distros for the next years. Rustc is so alpha, that it doesn't even compile (eg. wrong guesses on the target architecture, neeed bleeding-edge cmake, ...) I'd rather concentrate on consequent cleanups, starting with dropping bundled 3rdparty libraries, dropping various misfeatures, esoteric build systems, move audio/video stuff to separate tools that are really made for that (eg. ffmpeg or gst - yes, that gives you hw acceleration for free), move out mail protocol handling to separate service (mailfs is your friend) - same for address books, dictionaries, bookmarks finally an lightweight interface to run extensions as separate programs. When I look back the past decade, I don't recall any major improvement (okay, don't remember whether session management did exist back then), but it just got slower and slower, even w/ magnitudes faster machines since back then. Will moving to rust improve anything of these areas ? - Lack of Rust expertise for both writing and reviewing code. We have some pockets of expertise, but these need to be expanded greatly. Wouldn't that be a yet another big argument for keeping rust stuff optional, until that problem is settled (and rust is matured enough so become an option for production systems ?) - ARM/Android is not yet a Tier-1 platform for Rust. See https://forge.rust-lang.org/platform-support.html and https://internals.rust-lang.org/t/arm-android-to-tier-1/5227 for some details. So, is android also dropped out of the list of supported platforms, just like all recent stable gnu/linux distros already are ? - Compile times are high, especially for optimized builds. Compile times for C++ are already very high (c++ in general is very expensive to compile, and also very complicated to write good code). How much worse is that for rust ? --mtx ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Proposed W3C Charter: (Accessibility) Education and Outreach Working Group
The W3C is proposing a revised charter for: (Accessibility) Education and Outreach Working Group https://www.w3.org/WAI/EO/charter2017 https://lists.w3.org/Archives/Public/public-new-work/2017Jul/0003.html Mozilla has the opportunity to send support, comments, or objections through Thursday, August 10. If this is work that we want to see happen at W3C, we should explicitly support it; if there are things we think should be different about the charter, this is the time to say so. Please reply to this thread if you think there's something we should say as part of this charter review, or if you think we should support or oppose it. -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: PGP signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
