Re: Rust crate approval

[Lars Bergstrom]

Cool! I was just worried, especially since hyper and tokio/mio are
*already* vendored in-tree (though openssl is not yet). It appears they're
used for network access in some test tools and an audio ipc server
prototype. So we're not talking about a bunch of code "appearing" in
third-party, but rather people knowing that they can use certain components
in one part of the tree (presumably test/non-product code?) and not in
another.

This topic also isn't entirely academic, as I was in a conversation with
some folks at the SF all hands unaware of the issues with using a different
(Rust) network & TLS stack in some new code they are writing in their
Firefox modules.
- Lars


On Mon, Jul 2, 2018 at 1:23 PM, Bobby Holley  wrote:

> I think the key distinction here is that, unlike other rust-based projects
> (i.e. Servo), Firefox vendors all cargo dependencies into the tree, so it's
> more obvious to reviewers when a patch indirectly pulls in a new large
> dependency. In Servo the reviewer would have to look carefully at the
> Cargo.lock diff, where it's easier to miss.
>
> This does mean, however, that reviewers should _not_ just rubber stamp any
> changes in third_party Rust. A line-by-line review may be too much to ask
> in some cases, but the reviewer should at least look at what's added and
> removed and make sure it's sane.
>
> On Sun, Jul 1, 2018 at 7:24 PM Eric Rescorla  wrote:
>
> > On Sun, Jul 1, 2018 at 4:56 PM, Xidorn Quan  wrote:
> >
> > > On Mon, Jul 2, 2018, at 9:03 AM, Eric Rescorla wrote:
> > > > On Sat, Jun 30, 2018 at 9:35 AM, Lars Bergstrom <
> larsb...@mozilla.com>
> > > > wrote:
> > > >
> > > > > On Fri, Jun 29, 2018 at 8:33 AM, Tom Ritter 
> wrote:
> > > > >
> > > > > >
> > > > > > I know that enumerating badness is never a comprehensive
> solution;
> > > but
> > > > > > maybe there could be a wiki page we could point people to for
> > things
> > > that
> > > > > > indicate something is doing something scary in Rust?  This might
> > let
> > > us
> > > > > > crowd-source these reviews in a safer manner. For example, what
> > > would I
> > > > > > look for in a crate to see if it was:
> > > > > >  - Adjusting memory permissions
> > > > > >  - Reading/writing to disk
> > > > > >  - Performing unsafe C/C++ pointer stuff
> > > > > >  - Performing network connections of any type
> > > > > >  - Calling out to syscalls or other kernel functions (especially
> > > > > win32k.sys
> > > > > > functions on Windows)
> > > > > >  - (whatever else you can think of...)
> > > > > > <https://lists.mozilla.org/listinfo/dev-platform>
> > > > > >
> > > > >
> > > > > ​Building on that, is there a list of crates that should *never* be
> > > > > included in Firefox that you could scan for? Such as, anything that
> > is
> > > not
> > > > > nss (openssl bindings) or necko (use of a different network stack
> > that
> > > > > might not respect proxies, threading concerns, etc.)​?
> > > >
> > > > Is this a crate-specific issue? Suppose that someone decided to land
> > > > a new C++ networking stack, that would presumably also be bad but
> > > > should be caught in code review, no?
> > >
> > > The point is that adding a new crate dependency is too easy
> accidentally,
> > > and it is very possible for reviewers to overlook that. So it may make
> > > sense to introduce a blacklist-ish thing to avoid that to happen.
> > >
> >
> > But in order for it to have an effect other than just cluttering up the
> > build, it would have to be wired into Firefox. And if reviewers don't
> > notice that, we have bigger problems.
> >
> > -Ekr
> >
> > - Xidorn
> > > ___
> > > 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rust crate approval

[Lars Bergstrom]

​

On Fri, Jun 29, 2018 at 8:33 AM, Tom Ritter  wrote:

>
> I know that enumerating badness is never a comprehensive solution; but
> maybe there could be a wiki page we could point people to for things that
> indicate something is doing something scary in Rust?  This might let us
> crowd-source these reviews in a safer manner. For example, what would I
> look for in a crate to see if it was:
>  - Adjusting memory permissions
>  - Reading/writing to disk
>  - Performing unsafe C/C++ pointer stuff
>  - Performing network connections of any type
>  - Calling out to syscalls or other kernel functions (especially win32k.sys
> functions on Windows)
>  - (whatever else you can think of...)
> 
>

​Building on that, is there a list of crates that should *never* be
included in Firefox that you could scan for? Such as, anything that is not
nss (openssl bindings) or necko (use of a different network stack that
might not respect proxies, threading concerns, etc.)​? Sort of in the same
way that (I assume) you are checking for prohibited licenses in the
Cargo.toml.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [dev-servo] PSA: Avoid invoking Debug formatters in release-mode Rust

[Lars Bergstrom]

At least for Servo, should we add a check to tidy (
https://github.com/servo/servo/blob/master/python/tidy/servo_tidy/tidy.py)
immediately to catch the use of that fairly-unique formatting string, as we
do for a bunch of other random stuff? We can always exempt particular
files/folder where we think it shouldn't matter, but if it's that easy to
footgun we might as well put some simple guards in place.
- Lars

PS - welcome back!

On Fri, Jan 12, 2018 at 11:07 PM, Bobby Holley 
wrote:

> TL;DR: To prevent code bloat, avoid {:?} in format strings for panic!(),
> unreachable!(), error!(), warn!(), and info!() for Rust code that ships in
> Gecko.
>
> Longer version:
>
> One nice thing about Rust is that you can #[derive(Debug)] for a type, and
> the compiler will generate a stringification method, which may in turn be
> inductively defined in terms of the Debug implementations of member types.
> This is great for logging and debugging, but the implementations can be
> quite large depending on the types involved.
>
> The linker will generally eliminate unused Debug implementations as dead
> code, but can't do so if they might be invoked in release builds. The most
> common way this seems to happen is in panic!() messages, where it can be
> tempting to include a stringified value to make the message more
> informative. It can also happen for the logging macros that don't get
> compiled out of release builds, which (at least for stylo) are info!(),
> warn!(), and error!() [1].
>
> To demonstrate what's at stake here, this trivial patch eliminates more
> than 80K from libxul: https://github.com/servo/servo/pull/19756
>
> Given how easy it is to mess this up and pull tons of unnecessary code into
> Firefox, and given that it's rather time-consuming to notice the problem
> and track down the culprit, I think we're best off categorically avoiding
> this pattern.
>
> Comments and alternative proposals welcome.
>
> bholley
>
>
> [1]
> https://searchfox.org/mozilla-central/rev/7fb999d1d39418fd331284fab909df
> 076b967ac6/servo/ports/geckolib/Cargo.toml#21
> ___
> dev-servo mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: WebVR Working Group

[Lars Bergstrom]

Thanks, Tantek! I like this response. I have not been able to reach
google/microsoft but will inform them of this intention.

To reinforce point #1, I'd add that WebVR is currently under TAG review
(see https://github.com/w3ctag/design-reviews/issues/185 ). Standardization
is definitely the intended path here.
- Lars

On Thu, Aug 17, 2017 at 5:33 PM, Tantek Çelik <tan...@cs.stanford.edu>
wrote:

> Given that we have a day left to respond to this poll, we should begin
> writing up at least a draft answer with known facts that we can
> iterate on as we get more information.
>
> Rough draft WebVR proposed charter response points for consideration:
>
>
> 1. Timing is good. We think WebVR is ready for a WG to formally
> standardize it.
>
> [Our very action of shipping a WebVR feature publicly (without pref)
> speaks louder than any words on any email lists (including this one)
> and communicates that we think WebVR is ready for adoption on the open
> web (if that were not true, we should not be shipping it publicly, but
> my understanding is that that decision has been made.), and thus ready
> for rapid standardization among implementers.]
>
> 2. WG charter details bad. We have strong concerns about the proposed
> WG charter as written, including apparent disconnects with the CG, and
> in particular failure to involve  implementers (e.g. browser vendors
> and major hardware providers).
>
> 3. Conclusion: Formal objection. Charter bad, needs to be withdrawn,
> be rewritten in an open dialog with the CG, such that there is at
> least rough consensus with the CG on scope, chairs, and other details.
>
>
> I believe these points reflect our actions and what Lars has communicated
> below:
>
> On Thu, Aug 17, 2017 at 9:14 AM, Lars Bergstrom <larsb...@mozilla.com>
> wrote:
> > I'll follow up more with the chairs of the community group (they just
> had a
> > face to face earlier this week and I presume it came up). The last bit
> that
> > I heard is consistent with what Dan mentioned -  the concern is not
> around
> > standardization
>
> Thanks for the clarification, thus point 1.
>
> > but that neither the chairs nor the browser vendors nor the
> > major hardware providers were consulted publicly in the creation of a
> > proposal to transition to a working group:
> > https://lists.w3.org/Archives/Public/public-webvr/2017Jul/0083.html
>
> Thus point 2.
>
> > Based on that thread, I'd expect the proposal to be withdrawn or - as Dan
> > mentioned - things adjusted to involve the the current spec contributors.
>
> Thus point 3 - we should openly advocate for the proposed charter to
> be withdrawn and rewritten accordingly.
>
>
> > I'll try to get on the phone with folks to find out more and get
> something
> > to dbaron by tomorrow. I'm not familiar with the inner workings of the
> W3C,
> > but I find it hard to imagine how things will go well with none of the
> > current spec contributors involved.
>
> Short answer: historically when W3C WGs move forward without strong
> implementer participation, they have very low chances of success, high
> chances of failure, and especially of damaging good will in relevant
> communities. Your concerns are merited.
>
> More information definitely appreciated to help iterate on our response.
>
> Thanks Lars,
>
> Tantek
>
>
> > On Wed, Aug 16, 2017 at 10:46 PM, Eric Rescorla <e...@rtfm.com> wrote:
> >
> >>
> >>
> >> On Wed, Aug 16, 2017 at 5:18 PM, Daniel Veditz <dved...@mozilla.com>
> >> wrote:
> >>
> >>> On Wed, Aug 16, 2017 at 3:51 PM, L. David Baron <dba...@dbaron.org>
> >>> wrote:
> >>>
> >>> > I still think opposing this charter because the group should still
> >>> > be in the incubation phase would be inconsistent with our shipping
> >>> > and promotion of WebVR.
> >>> >
> >>>
> >>> I agree that would be exceptionally odd and require a well reasoned
> >>> argument about why formal standardization was inappropriate.
> >>>
> >>
> >> This puzzles me as well. Lars, can you explain what the argument against
> >> standardization of a shipping feature is?
> >>
> >> -Ekr
> >>
> >>
> >>>
> >>> I'm troubled that the members of the incubation group seem to feel that
> >>> chairs are being imposed on them who have been less involved (or
> >>> uninvolved?) with leading the feature to the point it's gotten so far.
> But
> >>> I don't understand the politics of that or whether we could or should
> get
> >>> involved on that point.
> >>>
> >>> -Dan Veditz
> >>> ___
> >>> 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: Proposed W3C Charter: WebVR Working Group

[Lars Bergstrom]

Thanks for pointing that text out, Jet! Samsung Internet, Oculus Browser,
Microsoft Edge, and Firefox have all either shipped or have plans to ship
the released version of the WebVR API (see
https://blog.mozilla.org/blog/2017/06/01/mozilla-brings-virtual-reality-to-all-firefox-users/
for a table) and support it, even after the (non-breaking) work is done to
evolve the API. I'll work with our colleagues to update the language there,
since it's clearly inconsistent with our commitments. And the fact that, as
David alludes to, not only are browser vendors shipping it, but major tool
vendors and frameworks are relying on it. A-Frame content alone is
downloaded more than 12 million times a month, and there's at least as much
WebVR content out there that uses other frameworks or raw access to the API.

w.r.t. the "deprecated" vs. draft APIs, a hard constraint on the current
effort is that there are no breaking changes and both versions can be
supported side by side or from one to another via a polyfill. Our current
plan is to implement one and support the other via polyfill, but other
browser engines plan to support both natively.

w.r.t. hardware vendors, I would expect them to participate more heavily in
the OpenXR effort, which will define which of their hardware features will
be exposed to all native VR applications. We hope to support to that in the
future, but it will take time for all that to shake out. Fortunately, OSVR
and OpenVR get us at least basic access to the majority of desktop VR
devices, though mobile is currently still evolving and a bit more messy.
- Lars



On Wed, Jul 12, 2017 at 3:31 PM, Jet Villegas <jville...@mozilla.com> wrote:

> There's a lot of maneuvering going on with all the WebVR browser vendors
> about which VR hardware vendors will get "Tier 1" support. The support
> matrix can get quite complex as more vendors come in, and many of these new
> vendors will not be W3C members. It would be good to encourage a more
> inclusive spec process that doesn't unfairly burden new entrants with
> unnecessary bureaucracy.
>
> That said, I'm concerned about the ambiguity around specs like WebVR 1.1
> (which we're shipping in FF55). From the spec draft
> <https://w3c.github.io/webvr/spec/1.1/>:
>
> *Deprecated API*
>
>
> *The version of the WebVR API represented in this document is does not
> represent the final shape of the API. While the API is being finalized
> support for this version may temporarily be available in some browsers but
> is expected to be replaced eventually.*
>
> The statement above is weird to me. While I do expect that APIs evolve
> over time, just as most Web APIs do, it seems rather heavy-handed for the
> spec editor to state ship/support policy for all the browser vendors.
> Vendors may decide to support for this API long-term, or not support a 2.0
> API, or decide to work on 2.0 for a while but still allow for users to
> build WebVR apps today. In any case, vendors are shipping to their release
> channels, and we should have more rigor around what that  means for
> "experimental" features.
>
> --Jet
>
>
>
>
> On Wed, Jul 12, 2017 at 12:20 PM, L. David Baron <dba...@dbaron.org>
> wrote:
>
>> On Wednesday 2017-07-12 06:48 -0500, Lars Bergstrom wrote:
>> > There is some contention in the WebVR community group around the
>> submission
>> > of this charter proposal, as there is currently no public support from
>> any
>> > of the implementers in making this transition away from a community
>> group:
>> > https://lists.w3.org/Archives/Public/public-webvr/2017Jul/0056.html
>>
>> That's a little confusing to me given that there has been a good bit
>> of movement towards shipping WebVR in release versions of browsers.
>>
>> Shipping things to the release channel (as opposed to just users on
>> nightly/beta channels or users who turn on experimental features)
>> means that Web content could start depending on the features at any
>> time, which means we might be stuck with them in their current form.
>>
>> That suggests (if my understanding of the state of shipping to
>> release users is correct) that it's likely time for the
>> standardization process to also admit that it's no longer just
>> experimenting, but actually shipping real stuff.
>>
>> -David
>>
>> > I would certainly not support at this time and, depending on the
>> > conversations in that group and timing of the below deadline, may
>> suggest
>> > that we oppose.
>> > - Lars
>> >
>> >
>> > On Tue, Jul 11, 2017 at 12:23 PM, L. David Baron <dba...@dbaron.org>
>> wrote:
>> >
>> > > The W3C is proposing a new ch

Re: Proposed W3C Charter: WebVR Working Group

[Lars Bergstrom]

There is some contention in the WebVR community group around the submission
of this charter proposal, as there is currently no public support from any
of the implementers in making this transition away from a community group:
https://lists.w3.org/Archives/Public/public-webvr/2017Jul/0056.html

I would certainly not support at this time and, depending on the
conversations in that group and timing of the below deadline, may suggest
that we oppose.
- Lars


On Tue, Jul 11, 2017 at 12:23 PM, L. David Baron  wrote:

> The W3C is proposing a new charter for:
>
>   WebVR Working Group
>   https://www.w3.org/2017/07/vr-wg-charter.html
>   https://lists.w3.org/Archives/Public/public-new-work/2017Jul/0002.html
>
> Mozilla has the opportunity to send support, comments, or objections
> through Friday, August 18.  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)
>
> ___
> 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: All about crashes

[Lars Bergstrom]

On Jun 3, 2016, at 8:53 AM, Ted Mielczarek  wrote:

> On Wed, May 25, 2016, at 10:27 PM, Eric Rescorla wrote:
>> - Making it so that certain kinds of defects still happen but they are
>> safer.
>>  For instance, in C writing dereferencing past the end of an array is
>>  undefined behavior and may well cause something horrible, in Python
>>  you get an exception, which, if not caught, causes program termination.
>>  It's safer in the sense that it's unlikely to cause a security
>> vulnerability,
>>  but it's still a crash.
> 
> Right. There are two main reasons we track and fix crashes:
> 1) They are often a sign of potentially exploitable code, and we don't
> want security holes in our product.
> 2) They create a bad user experience.
> 
> Moving code from C++ to JS or Rust improves our story around #1, since
> it mitigates classes of vulnerabilities, but it still leaves us open to
> #2, where we terminate the app unexpectedly and users are unhappy. I
> think Rust does give us a better story here, since we can safely
> restrict panics to individual threads, and as long as you don't unwrap
> the thread result you don't have to propagate that panic across threads.

To add to #2, restricting panics is a key part of the design of Servo. We work 
pretty hard to ensure that a panic in a single iframe is isolated from the rest 
of the tab so that we can just crash the buggy ad banner, social media widget, 
etc. and hopefully keep the main content acting normally.

Certainly, there are some places where that's hard for us to do (shared tasks 
such as resource loading, only taking down one of several same-origin iframes 
sharing a script task / SM JSRuntime instance, etc.) but we hope that using 
Rust to install backstops a point more fine-grained than the entire tab or 
content process will be a big improvement. It will also be challenging to 
replicate in C++ with the thread-per-tab or process-per-domain models either in 
use or planned in other engines.
- Lars
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: multiple Rust crates are now supported

[Lars Bergstrom]

Agreed! Thanks to you, Ralph, and everyone (especially the build
peers!) who has been providing feedback/reviews and trying to stand up
examples integrating various Rust or Servo code into Gecko so that we
could find the blockers quickly.

For people who would like to follow along without adding themselves to
all of the bugs, we try to keep https://wiki.mozilla.org/Oxidation up
to date with the current status of this integration work.


On Thu, Apr 21, 2016 at 10:38 AM, Ralph Giles  wrote:
> Thanks, Nathan. This is really great to see!
>
>  -r
>
> On Thu, Apr 21, 2016 at 7:57 AM, Nathan Froyd  wrote:
>> Bug 1163224 has landed on inbound, which means that Gecko builds with
>> --enable-rust now support multiple Rust crates.  This change is
>> intended to make the lives of people developing Rust components
>> easier, and it comes with several caveats:
>>
>> 1) There is zero support for interdependencies between crates, so you
>> have to structure your crate as one big crate that includes any
>> dependencies, rather than several separate crates, as is the norm.
>> This is clearly suboptimal, and it will be fixed.  I think it's an
>> open question exactly how we're going to integrate multiple crates and
>> external projects anyway, so feel free to experiment!
>>
>> 2) We do not have Rust support on all of our Tier 1 platforms (Android
>> is still being worked on), so actually depending on Rust code
>> everywhere is still not possible.
>>
>> 3) Due to bug 1178897, Rust code uses a completely different memory
>> allocator than the rest of Gecko.  We therefore don't have any
>> visibility into Rust's memory allocations through things like
>> about:memory, using Rust code worsens fragmentation issues, and there
>> are also edge cases with allocating in C++ and freeing in Rust (or
>> vice versa).  This is obviously something we're going to fix, ideally
>> soon.
>>
>> We --enable-rust on all of our Tier 1 desktop platforms, but given 2)
>> and 3) above, it seems best to limit the amount of Rust code we
>> actually ship.  So if you want to land Rust components in-tree right
>> now, I'd recommend gating your component behind an --enable-shiny
>> configure option.  Ideally 2) and 3) will be fixed in short order, 1)
>> will be ironed out, and then the real fun can begin!
>>
>> Thanks,
>> -Nathan
>> ___
>> 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: Rust and Servo training sessions at Whistler

[Lars Bergstrom]

On Jun 22, 2015, at 11:02 AM, Ms2ger ms2...@gmail.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 On 06/22/2015 05:51 AM, J. Ryan Stinnett wrote:
 On Sched, it appears the Servo session is scheduled for Friday, 1 -
 3 PM, is that now the correct date and time?
 
 That's correct.

Yes, it had to be moved due to conflicts with several other events that were 
booked overlapping with it on Wednesday. That said, in its new spot it both 
conflicts with far fewer things *and* is actually after the Rust training, 
which will hopefully help increase the type of exercises we can have.

Sorry if this messed up your schedule!
- Lars
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rust and Servo training sessions at Whistler

[Lars Bergstrom]

Jim,

We won’t get into anything that requires prior Rust experience during the Servo 
session - the focus is intended to be more on architecture, web platform 
compat, and with a bit of poking around to make small changes (e.g., either 
fixing or breaking WPT and CSS WG ref tests with tiny code changes).

Ideally, we would have had the Rust one first, but the Thursday slot had fewer 
conflicts and there were more groups interested in the Rust training than the 
Servo one.
- Lars

On Jun 8, 2015, at 5:15 PM, Jim Chen nc...@mozilla.com wrote:

Does the Servo session (which is earlier than the Rust session) require prior 
experience with Rust?

Thanks,
Jim


On 6/8/15 3:44 PM, Lars Bergstrom wrote:
 The Research team will be holding a pair of 3 hour training sessions, with 
 one on the new web rendering engine, Servo, and one on the new systems 
 language it is implemented in, Rust. These sessions will have both 
 presentation components and a large hands-on piece with exercises to do on 
 your laptops. The Rust session will also have some content on building Rust 
 code into Gecko.
 
 If you are interested in attending, please sign up on the Sched links below 
 (you will have to log in and then click the “Add To My Sched” button). The 
 numbers will help us figure out how many USB sticks to bring, how many people 
 we need to have staffing the training, whether there is enough space in the 
 booked room, whether we have enough stickers, etc.
 
 The Platform admins and managers have helped ensure that the Rust session 
 will not conflict with any team’s meetings and that the Servo one will not 
 conflict with meetings for teams that work on browser features, so you 
 shouldn’t need to worry about something getting booked over them.
 
 Servo - Wednesday, 1–4 PM: http://sched.co/3ZQn http://sched.co/3ZQn
 Rust - Thursday, 1–4 PM: http://sched.co/3ZQp http://sched.co/3ZQp
 
 Please don’t hesitate to reach out if there are specific things you’d like to 
 see us cover, as we’re making up the training materials right now.
 
 Thanks!
 - Lars
 ___
 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