Re: [dev-servo] The future of irc.mozilla.org/#servo

[Lars Bergstrom]

Has anybody got experience with the Discord<->Matrix bridge (
https://matrix.org/bridges/#discord )?

Like the rest of Mozilla, I don't particularly enjoy Discord's terms of
service / privacy policy, but I'm part of a zillion Discord servers for
other communities. Whereas #servo IRC is my last remaining (active) IRC
channel.
- Lars

On Thu, Dec 19, 2019 at 10:43 AM Josh Bowman-Matthews 
wrote:

> Hi folks! Mozilla has announced [1] that irc.mozilla.org is being
> officially replaced by an instance of Riot/Matrix, so we now need to
> make a decision about what happens next. The server will shut down in
> March 2020, and I see two possible outcomes for our official day-to-day
> synchronous project discussions:
> 1) a #servo channel on the Mozilla Matrix instance
> 2) a #servo channel on irc.freenode.org
>
> Beyond the question of personal comfort with chat clients, I can think
> of the following considerations:
>
> * logging - we currently rely on http://logs.glob.uno/ for persistent
> channel logging, run by a Mozilla employee.
>
> * bots
>* crowbot is an IRC bot whose biggest responsibilities include github
> link integration, collecting standups entries, and recording messages
> for users who aren't online.
>* bitbot is an IRC bot responsible for reporting github updates to
> repositories under the servo organization
>
> Please be aware that there exists an IRC gateway for Matrix which
> ajeffrey has successfully used, so if you really like your IRC client
> that isn't _necessarily_ a complete blocker.
>
> Am I forgetting anything? I'm on the fence about the choice right now,
> and I would like to hear from people who semi-regularly contribute to
> discussions (or have a particular interest in lurking) if they have a
> preference.
>
> Cheers,
> Josh
>
> [1]
>
> https://discourse.mozilla.org/t/synchronous-messaging-at-mozilla-the-decision/50620/2
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] ./mach build vs. cargo build

[Lars Bergstrom]

Cargo has traditionally not wanted to add full support for arbitrary
RUSTFLAGS, for reasonable reasons:
https://github.com/rust-lang/cargo/issues/60#issuecomment-51705597

What we've done in the past is for each flag that we needed exposed opened
a specific Issue or PR to Cargo to have just that one feature either added
to the allowed flags list or as a new toplevel item in the profile. I'd at
least check those out first before regressing link performance
significantly or adding a local development footgun (only checking certain
warnings in CI and requiring people to take an extra trip through the homu
queue to find out things they could have tested locally).

FWIW, I agree totally - any reasonable IDE is not going to respect usage of
`mach` to set env vars and we'd LOVE to have all this stuff in Cargo
configs. The use of RUSTFLAGS in mach has traditionally been a staging area
for features not yet turned on by default in rustc or not yet supported for
configuration in cargo (especially in the dark old days of cross
compilation woes - much better now!).
- Lars


On Tue, Apr 3, 2018 at 4:44 PM, Simon Sapin  wrote:

> On 03/04/18 23:30, Emilio Cobos Álvarez wrote:
>
>> or the bit to use the gold linker.
>>
>
> The best outcome IMO would be to make that the default:
> https://github.com/rust-lang/rust/issues/30783
>
> This was implemented and then reverted because of Debian Wheezy
> (oldoldstable), whose LTS ends next month in May.
>
> My pings on the issue a few months ago did not get a response, so the next
> step is probably sending a PR and picking someone on the compiler team to
> nag for review.
>
> --
> Simon
>
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Standalone NDK concerns?

[Lars Bergstrom]

The standalone NDK's problem is that we moved to use the same C++ standard
library as Firefox in order to match SM when Gecko made the move.
Unfortunately, the make-standalone-toolchain.sh script was broken for years
for anything apart from the default C++ standard library (it would either
just break using wrong directories or fail to pick up all the right
headers, depending on the version). Therefore, I adopted the identical
strategy for picking up headers and setting include paths that Firefox was
using, again to make sure we picked up the same definitions since we were
passing those flags down to SM.

If that has since been fixed, I'm not against returning to the standalone
NDK, though tbh it was also a huge source of user confusion. We had
versioned SDK and NDK directories but then an *unversioned* NDK toolchain
directory that developers needed to know to blow away and update every time
they picked up a new version. Certainly, could automate this away per your
suggestion below!
- Lars


On Wed, Mar 7, 2018 at 8:48 AM, Josh Bowman-Matthews 
wrote:

> On 3/7/18 6:04 AM, Imanol Fernández wrote:
>
>> We talked a bit about standalone NDKs when we worked on adding support for
>> new android CPU architectures here:
>> https://github.com/servo/servo/issues/11921#issuecomment-299052122
>>
>> The benefit of using a standalone NDK is that we have to configure less
>> CXX
>> flags in Servo. But the main concerns are that is another step and failure
>> point for people building for Android. Also we have to create different
>> standalone NDKs for each architecture: armv7, arm64, x86, etc which can
>> increase build sizes and steps for the user.
>>
>> IMO is better that we assume the CXX flags set up complexity and only make
>> the users to set up the PATH to the default android-ndk folder. At least
>> that's the usual way to compile android libraries. In fact, I had never
>> heard of standalone NDKs after a lot of time working & compiling libs for
>> Android until I worked on that Servo integration.
>>
>
> One way we could continue to assume the complexity is by creating the
> standalone NDK as part of the regular build. If the build system checks for
> a .android directory that contains an NDK for the desired target, it goes
> ahead and builds with the right settings. Otherwise, it checks for the
> presence of the ANDROID_NDK path and invokes the make_standalone_ndk.sh
> with the right arguments to create one in .android.
>
>
> Cheers,
> Josh
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Dropping CEF support?

[Lars Bergstrom]

I've talked with the CEF owner, Mike from Samsung, and given how long the
blocking issues (see below) have been open and preventing use of or
additional work on CEF, he's OK with removing the support.
- Lars

https://github.com/servo/servo/issues/10274

https://github.com/servo/servo/issues/17663

https://github.com/servo/webrender/issues/933

https://github.com/servo/servo/issues/4024


On Mon, Jan 29, 2018 at 9:49 PM, Paul Rouget  wrote:

> > What does "3rd party project" mean in this case? It's not clear to me
> how you could do a CEF wrapper externally without forking and removing
> glutin entirely.
>
> Why do we need glutin for CEF? If I'm not mistaken, the only part of
> glutin that is useful in this case is creating the GL buffer, right?
> And that's not hard to do manually.
> So CEF could live in another project. Use servo as a dependency. Like
> we did for servoshell (where we don't rely on Glutin). All we need to
> do is 1) create the gl buffer, 2) implement a simple event loop, 3)
> forward the events as needed. We don't need glutin for that.
>
> I might be missing something though. Let me know.
>
> > What is the full set of features we're missing in upstream glutin?
>
> Reparenting. Logo support.
>
> > And can we uplift them?
>
> Likely. But that requires some work (logo support should be easy).
>
> My reasoning is because of 1) CEF is not maintained, 2) CEF could be
> designed better (no dependency on glutin), 3) we need to unfork
> glutin; dropping CEF would make our life easier.
>
> In the future, if anyone is interesting in maintaining CEF, they can
> revive the old code (using glutin or not, and as part of servo/ports
> or not).
>
> Embedding is possible today, on Desktop and mobile, but not via CEF.
> If we decide that embedding *via CEF* is important now, then I'm happy
> to try to upstream the reparenting code.
>
> This will just delay unforking glutin more. That's it.
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

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-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] [stylo-team] Mozilla central backout support arriving to Servo later this week

[Lars Bergstrom]

Opinions vary.

From my point of view, if we attempt another subsystem transplant across a
code boundary that lacks clean separation (e.g., parallel layout), then we
will continue to need this coupling in the future.

If we instead get to a point where most of the modules that Firefox is
using from Servo have relatively stable APIs, the two projects each have
their own product ship cycles, and these modules are just as easy to treat
like normal vendored code, then I could see us disabling the coupling.

Given the number of people who are currently doing coordinated changes with
major bustage across the API boundary in the two codebases today, I do not
see us turning this off in the near future. Unless, of course, things go
horribly awry with the infra or process in a way that puts Firefox at risk,
in which case all bets are off :-)
- Lars


On Tue, Jun 20, 2017 at 4:17 AM, Anthony Ramine  wrote:

> In the future, will we try to uncouple servo from mozilla-central? I
> understand that it is needed now, but I don't see how such coupling is a
> good thing on the long term.
>
> Le 19 juin 2017 à 21:25, Jack Moffitt  a écrit :
>
> Thank for everyone's efforts here. There never seems to be a perfect
> solution in technology, but I am happy we've found a solution that
> satisfies most of the constraints and were able to deploy it in time.
>
>
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Mozilla central backout support arriving to Servo later this week

[Lars Bergstrom]

tldr: If you see some PRs from the moz-servo-sync GitHub user with a
priority of "treeclosed," it's because those must be landed into Servo ASAP
to support Firefox backouts.

Due to some amazing work from gps, we already have support for taking code
changes that occur in Servo on Github and automatically pushing them to the
Firefox Mercurial servers. Now that stylo will soon be building by default,
we will need to go the other way, too - pushing changes made in Firefox
back to Servo.

The key first scenario here is supporting "backouts" from Firefox. Backouts
are basically undo commits that revert a change that the test-after-checkin
system has determined to be faulty. This manual process, performed by
administrators known as sheriffs, needs to be instant and atomic across the
repos. The solution that we've implemented is:
1) The backout / undo commit is landed in Firefox.
2) A PR is created on the Servo side, authored by the moz-servo-sync user,
with a priority that closes the Servo tree until the PR lands. This is
important due to the fact that we sync changes from Servo instantly and
automatically to Firefox, and do not want to have two versions of history
[1].
3) The PR is tested by homu and ultimately landed. If the undo commit from
the sheriffs does not actually compile or otherwise pass Servo tests, we
should push *additional commits* on top of the undo commit that fix up the
PR until it lands. The original commit authored by moz-servo-sync should
not be altered.

This process should only be hit in the event that there is a backout on the
Firefox side of things that also touches Servo code. Hopefully, such
backouts are extremely rare events, and should be even more rare once we
support a basic in-Firefox build & test for the geckolib code by homu.

We are planning to test this support via some dummy backouts (e.g., edits
to Readme.md) later this week, at a time when the queue is quiet.

Thanks for your patience as we roll this out and sort out any initial kinks
in the system!
- Lars

[1] There is a race condition here, where homu lands a commit to Servo
master but the vcs-sync has not propagated it to Firefox as the sheriff
performs the backout. We believe this window is only a few seconds and hope
not to hit it, but have some plans in place for how to manually fix up this
situation if it occurs, which will be separately documented.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Proposal: remove testing of and support for MinGW builds

[Lars Bergstrom]

Servo used the excellent MinGW toolchain to quickly stand up Servo builds
on Windows and to provide us with Windows debugging support while the MSVC
Rust toolchain was not yet ready. Now that the native MSVC is working well,
we would like to remove testing of and support for those MinGW builds.

MinGW is now an extra maintenance burden, is a platform where the Rust
toolchain support is getting more complicated (e.g.,
https://github.com/rust-lang/cargo/pull/3651#issuecomment-285380533), and -
to be perfectly frank - is a development mode that we do not want to
support or a build that we want to encourage users to use. Servo has pretty
good first-class support for development on Windows using the native tools
(thanks especially to UK992, vlad, Coder206, and WindowsBunny!). I would
not hesitate to suggest to a new developer that they work exclusively on
Windows without any ported linux tools, which is a solid point of pride for
any cross-platform open source project.

Opinions? Is there an important scenario here that I'm missing that
requires MinGW support? Or a particular tooling experience that is not yet
supported in the MSVC toolchain?

Thanks!
- Lars
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Android support

[Lars Bergstrom]

Thanks for driving this, Fabrice! That sounds like a great outline. From
the VR side, indeed what we're basically looking for is full screen app
support and WAY better integration with the Android lifecycle model
(orientation changes, background/foreground/close, intent handling, etc.).
I apologize in advance for the massive pile of hacks that you inherited
from my attempts to just stand something up :-)

Previously, our challenges with glutin have mainly been around:
1) Architectural lifecycle assumptions about resources that don't hold on
mobile. e.g., being able to hold on to a graphics context that won't get
ripped out from under you and need to be replaced
2) A lot of code that lives in the "android glue" area needs to be made
parameterizable or completely replaceable, along with the build steps, in
order to support more complicated apps or libraries

It wasn't clear to me from conversations with tomaka that these were
non-starters, and much of the pushback we had received in the past was
(justifiably!) that the code needed to support more user scenarios and have
more examples and testing in place than I was interested in doing for
one-off demo work at the time.

That said, I suspect that we would basically need enough hooks for Servo to
do completely its own thing for integration with all the myriad native and
Java services on Android, and I don't know how desirable such hooks are for
glutin.
- Lars



On Tue, Mar 7, 2017 at 5:26 PM, Jack Moffitt  wrote:

> > - glutin may not be something we want to keep using. I haven't looked in
> > details yet but glutin may be too high level an opinionated for us in
> this
> > context (eg. can glutin let us display several ServoViews?).
> >
> > So my current plan of action is to verify whether glutin is suitable or
> not
> > on Android, fix that if needed and then start on a ServoView
> implementation.
>
> We have had disagreements with the maintainer in the past. Glutin is
> primarily targeted at game developers, and our use cases are more
> advanced and not always welcomed. I'm not sure what it would take to
> modify Glutin (ie, create a new fork that goes in more useful
> direction for Servo) or create a new thing from scratch, but it's
> pretty much been our expectation that someday we would do one of
> these.
>
> jack.
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Gating on Android and Windows MSVC

[Lars Bergstrom]

Just wanted to make a public service announcement that:

1) We are gating on Android again. The fine team at Szeged working on Web
Bluetooth also helped pick our Android builds back off the floor after the
libc++ changes and we've re-enabled Android. Thanks to mmatyas and dati for
all their hard work!

2) We now have and are gating on a Windows MSVC builder. The Windows GNU
builder had, in practice, been pretty good at ensuring that Servo on
Windows continued to work, but we now will both have checks for MSVC and
are producing a separate MSVC nightly. The MSI contents on this one need
some work, but all of the CI server pieces are together, so it's "just" WiX
script polishing needed there.

Have a happy holidays!

With much evil CI overlord laughter,
- Lars
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Weekly status updates

[Lars Bergstrom]

On Mon, Sep 26, 2016 at 12:36 PM, Olaf Buddenhagen
 wrote:
> As a spare time outside contributor, it has become pretty much
> impossible for me to stay informed of what's happening in Servo land,
> since the meetings (and thus the meeting notes) have been cancelled;
> while few things are going over the mailing list; and the traffic on IRC
> is impossible to keep up with for anyone but full-time contributors.
>
> I have been reading the status updates for a while, but ultimately gave
> up on it, because many developers do not update them (regularily) at
> all; while some others provide a detailed changelog rather than a
> higher-level overview, making it very boring to read; and also, these
> updates mostly just tell what happened in the past, not what's brewing
> right now...
>
> Summing up, some way to stay in touch with ongoing/upcoming developments
> would be great -- but I'm not sure the status updates in their present
> form are very helpful in this regard.
>
> TWiS is somewhat useful with its nice high-level changelog -- but again,
> nothing about stuff in the works...

Thanks for the feedback! This is something I care a lot about. Are you
saying that you'd like to see something between
https://github.com/servo/servo/wiki/Roadmap, which gives what people
are working on for the rest of the quarter, and the "next week"
section of the status reporting?

Or are you saying that part of the problem is that we're not really
capturing the "next week" details well enough so that, e.g., you know
that Vlad's going to be looking into ipc-channel Windows support and
might need your feedback?
- Lars

BTW, I am full-time and I can't keep up with the IRC channel either.
And I (we) shouldn't! If IRC becomes a substitute for GitHub issues
and the mailing list, then it will crowd out both volunteers and
contributors who are not in the "right" timezone. I try to make sure
that people don't make *decisions* on IRC, as that's a pretty nasty
community anti-pattern, but I'm sure I've done it myself and should
definitely be called out when I do that.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Proposal: remove mingw Servo builds in favor of msvc

[Lars Bergstrom]

Now that Vlad has landed the amazing support for compiling with Visual
C++ instead of the mingw gcc toolchain, I'd like to propose that we
remove mingw from our automation, documentation, and support. There
are a few reasons:
1) Python is a total crazy mess. Users get messed up with the three
(3) different pythons installed, and we even have to ask them to
globally rename one of them.
2) Tracking mingw versions is pretty rough. The recent gcc update ICEs
in spidermonkey. They keep adding / removing / changing their launch
shortcuts, bitrotting our documentation.
3) Packaging. Figuring out which set of curiously-licenesed DLLs we
need to package up in our Windows installer is a challenge (much
easier in the MSVC case b/c we can merge in the usual MSM or point at
a different MSI & check for the installed product).

That said, I know that there are a few benefits on the mingw side:
1) Better gcc.
2) Contributors to the build / automation stuff can "fake it until
they make it" and hope that the macOS/Linux scripts they write just
happen to work on Windows in mingw.
3) Somebody might have a real mingw {something} that wants to include
Servo bits, and if we aren't testing mingw, it will almost definitely
break in the future.

Do people have opinions one way or another on this? I'm not dead-set
on removing it, and could definitely be convinced to just switch the
default to MSVC and hide the mingw documentation but keep testing it
if there are compelling reasons to do so.
- Lars
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Servo testing as part of PhD dissertation

[Lars Bergstrom]

On Wed, Sep 7, 2016 at 10:55 AM, Geoffrey Sneddon  wrote:
>>
>> However I think you might make progress with some sort of
>> consensus-based approach e.g. take a testcase and render it in
>> gecko/blink/webkit/edge. If the difference by some metric (e.g. number
>> of differing pixels, although more sophisticated approaches are
>> possible) is within some threshold then check whether servo is within
>> the same threshold. If it is consider that a pass otherwise a fail.
>
> FWIW, I was talking with a bunch of people in the Chrome team about such
> an oracle not that long ago. I think one can almost certainly come up
> with a useful oracle even though it'll have very real limitations.
>
> There are plenty of rendering bugs that don't involve text, and
> practically if you're generating arbitrary web pages it's easy to solve
> all of those problems by simply not including text (though you'll need
> to give boxes explicit heights!). Even if you allow text, you can
> probably get a long way by simply getting rid of all text and setting
> explicit width/height properties on everything such that the layout of
> the boxes doesn't change even if they're then empty. You can then
> compare the position of the box across browsers.

Along those lines, it's also worth looking at the very recent awesome
work at the University of Washington formalizing layout (upcoming
paper at OOPSLA):
http://cassius.uwplse.org/

I've been in contact with them with the hopes of trying it out in the
context of Servo, as I believe there are both some interesting testing
applications and some really nifty things that we could do with
devtools using such a tool, too.
- Lars
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Moving style out of tree as an alternative to frankenbuild?

[Lars Bergstrom]

On Thu, Aug 25, 2016 at 1:55 PM, Manish Goregaokar  wrote:
>
> There are a lot of issues with this.

I agree that there are challenges with mirroring the root Servo
repository into m-c, but I'd like to make sure we mention some of the
positives that we get from it:
- Having "servo" in-tree means that Gecko developers will be actively
contributing to both Gecko and Servo itself. This is a huge win for
Servo. We're a small team, and even though we have a great volunteer
community, Gecko is a source of deep area experts that are really
difficult to find or grow elsewhere. Doing things that make it easier
for them to contribute is really going to benefit the project.
- I want to see parallel layout in Gecko. And I want to see Gecko
developers helping us gut, replace, and share other components (media,
net, etc.) that make both browser engines better. Mirroring Servo
in-tree is the best way to do that for components that - like style -
are deeply integrated in the browser engine and cannot meaningfully be
"split out" into a repository with stable APIs.

> It increases cycle times for Servo PRs.
> We'd need to move wpt out of tree, which discourages people from writing
> tests (see the thread about tests/). Backouts on m-c tip may cause worse
> problems.

I would only expect this to increase cycle times for PRs to Servo that
touch the geckolib bits - otherwise, we will just be running the good
'ole Servo infrastructure pieces, with just our known cycle times and
intermittent woes.

After some brainstorming, one idea that came up is that we could leave
the tests in the servo repository, but in the mirrored copy in m-c, we
will not copy in the tests. They'd still be run in Servo's automation,
and there's an interesting edge case where m-c developers who add a
feature to style that makes a new test pass may need to update the
servo test manifest but can't see the test in-tree, but that doesn't
seem like a huge problem. Developers coming from the servo/servo side
would still be able to add new tests in the normal way.

And let's be clear upfront about backouts - the expectation is that
there will be *no* backouts affecting the branch in which servo would
be mirrored (servo-inbound) except in the case where two commits to
servo-inbound had no merge conflict but had a semantic conflict and
were not tested against a common master. If we end up in a state with
frequent tree closures or backouts, things have gone horribly wrong,
and Steps Will Be Taken. We've made a lot of effort to have pretty
solid CI on the Servo side, and 100% of the people I talk to in
similar positions on the Firefox side want to be in a similar place
themselves and support us on our way there.

> The downsides of this model are:
>
> Servo has to periodically sync with style and resolve conflicts. I volunteer
> as tribute to do these. I suspect they won't be too bad, and once stylo
> settles down a bit there won't be many breaking changes.
> Landing simultaneous changes to style/ and layout/ becomes harder. We have
> path deps to simplify working on these, and landing them is two-step now,
> something we're already used to for other crates (and it's easier for style
> because it will be a git dep, not crates.io). There is the issue of changes
> to style and layout that change style's public API or otherwise break m-c.
> We may need to frankenbuild anyway for layout if gecko ever wants to use
> that. Though afaict that's in the far future if it ever happens, and the
> solution space will probably have changed by then. Layout could probably be
> split out if necessary (the layout logic, not the RPC/IPC glue), since it
> mainly only talks to style.

So, I think the downsides here are much worse than stated. After
talking with Bobby (and seeing Emilio's mail) these are *not* changes
that merely require a pair of hands to update Servo to the changes.
The style system is not a natural module boundary with a stable
interface - many code and data representation optimizations need to be
deeply integrated between the two engines, and it sounds like often
only the person doing that change will have the background necessary
to do both. And I think that having a "you should also have a Servo PR
open" ideal is not going to fly. You might as well rename Servo to
ThunderServo :-) Even if everybody comes into this with the best
intentions, we do not have the tooling, process, or culture to support
that kind of workflow on a highly unstable module like that.

> I personally feel that the downsides aren't that bad, compared to the
> frankenbuild. It also isolates the downsides to one crate, a crate which
> would anyway be tricky to work with in the frankenbuild world.

tbh, I probably shouldn't ever have used the word frankenbuild, as it
makes everything seem a bit more monstrous and scary than it needs to
be :-) We're not proposing using two different build systems stitched
together. It's all cargo, all the time.
- Lars

Re: [dev-servo] Mentors needed (on IRC)

[Lars Bergstrom]

This is very exciting!

Shing, since you will be there in-person, if you could capture some of
the difficulties that people encounter when first getting started -
even if they overcome it themselves - I'd really appreciate it! I
don't have a good sense for how many people give up on contributing to
Servo before they ever reach the point of hitting the IRC channel,
etc., and this seems like a good opportunity to identify some of those
difficulties.

Good luck with the event,
- Lars


On Wed, Aug 24, 2016 at 9:00 AM, Shing Lyu  wrote:
> Jack, jdm, KiChjang,
>
> Thank you so much. Please don't feel obligated to stay up late, just peek
> at the IRC if you are free will be good enough.
>
>  - Shing Lyu | Mozilla Taipei
>
> 2016-08-24 3:27 GMT+08:00 Keith Yeung :
>
>> I happen to sleep pretty late, and actually write and read Traditional
>> Chinese, so I'm quite likely to be on that time! Otherwise, I think Ms2ger,
>> Manishearth, nox and waffles will be the people who are compatible with the
>> GMT+8 timezone.
>>
>> On Tue, Aug 23, 2016 at 8:39 AM, Jack Moffitt  wrote:
>>
>> > Also, if anyone has new E-easy's, it would be good to get them filed
>> > before this event so that the group has a reasonable amount to work
>> > on.
>> >
>> > jack.
>> >
>> > On Tue, Aug 23, 2016 at 3:13 AM, Shing Lyu  wrote:
>> > > Hi,
>> > >
>> > > I'll attend a bootcamp called "Taiwan Code Sprint", which is aimed to
>> > > introducing newcomers to contributing to open source projects, There
>> will
>> > > be roughly 4~6 people working on Servo E-easy bugs on Aug 27 & 28,
>> Taipei
>> > > Time (GMT+8).
>> > >
>> > > Since I can't be there all day. We'd appreciate if you can drop by the
>> > IRC
>> > > and Github issue/PRs more frequently during that time.
>> > >
>> > > Also, if you have any material about contribution workflow, codebase
>> > > overview, project ideas, etc., please kindly let me know. Hopefully we
>> > can
>> > > have attract more contributors! Thanks!
>> > >
>> > >  - Shing Lyu | Mozilla Taipei
>> > > ___
>> > > dev-servo mailing list
>> > > dev-servo@lists.mozilla.org
>> > > https://lists.mozilla.org/listinfo/dev-servo
>> > ___
>> > dev-servo mailing list
>> > dev-servo@lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-servo
>> >
>> ___
>> dev-servo mailing list
>> dev-servo@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-servo
>>
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox

[Lars Bergstrom]

On Mon, Aug 8, 2016 at 11:16 AM, Olaf Buddenhagen
 wrote:
>
>> This seems to trade time for machines by optimistically assuming all
>> previous PRs passed tests.
>
> Right.
>
> As long as intermittent failures are rare, I think it's a fair
> assumption. (Actual bugs showing up in pre-commit testing should be
> fairly rare, as most are already found by automated PR testing and
> optional manual try runs...)
>
> If we *do* have to deal with frequent intermittent failures, the many
> speculative runs can actuall come in handy, as I explained in the other
> followup.

I think part of the problem is that intermittents will continue to be
an ongoing problem - I've never seen UI-based testing that got
intermittents to zero, and not for lack of engineering effort. I'd
like to get the numbers down, but I'm really worried about the
experience for a new contributor submitting a PR. Already, there were
the possible failure modes of "is this my failure" vs. "is this an
intermittent," the latter of which the fine treeherder folk are
working to build tools that auto-detect.

But in this model, there's also "is this a failure from one of the N
PRs before me?" which isn't a type of failure that is common (AFAIK)
when contributing to OSS projects. Intermittents, especially when they
lead to PR bitrot, already chase off users in Servo. I'm worried this
extra failure mode will compound that problem.

Autorollup, bisection, etc. is also a LOT of extra code for the
autolander. As we've seen with homu (and the gecko autolander for that
matter), these don't seem to be projects that attract huge contributor
communities, despite the fact that lots of people rely on them.
Further, they're already incredibly fragile/sensitive to the Rube
Goldbergian setup of various build machines, platforms, networks to
various bits of cloud infra, etc. Putting on my manager hat, building
and rolling out all of this extra auto-retry/rollup stuff kinda scares
me, and I worry for the sanity of whomever is on call to keep such a
system chugging along.

That said, the world I wish we could be in is pre-commit testing, as
Servo has today. The autorollup approach does seem like one way to
scale things up a bit, and I'm not sure of any better solution (other
than possibly test selection/reduction) if you want to stick with
pre-commit testing.
- Lars
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Web console protocol support for Servo

[Lars Bergstrom]

> On Jul 8, 2016, at 10:36 PM, Manish Goregaokar  wrote:
> 
>> Our understanding is that your plan was to take out your Firefox devtools
>> protocol support and start implementing the Chrome protocol, once your June
>> demos were done. Have you started work on this?
> 
> Not that I am aware of. I'd be willing to help if I get time, though.

Yeah, this would definitely be great! Note that we shipped our June demos, but 
only on macOS and Linux. Windows and Android still have some more work :-)

>>> If not, the Devtools team has time for that in Q3-4, and people interested 
>>> in doing the work.
>> 
>> Our web console UI uses some HTML/CSS features that Servo doesn't yet
>> support. We could file bugs for these if they would be of interest to you;
>> would they?
> 
> Yes please :)
> 
> Might be worth creating some labels similar to the browserhtml ones to help
> prioritize these.

It would also be helpful to have some explicit scenarios or a target demo in 
mind to help drive some of the work. e.g., I was really interested in some of 
the ideas around debugging the layout process from our last meeting 
(https://github.com/servo/servo/wiki/Meeting-Devtools-Servo-2#killer-features ) 
and feel that driving towards a new feature that we could get in front of web 
devs might also help us get additional contributor/community excitement.
- Lars
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox

[Lars Bergstrom]

On Jun 21, 2016, at 8:39 AM, Boris Zbarsky <bzbar...@mit.edu> wrote:

> On 6/21/16 8:34 AM, Lars Bergstrom wrote:
>> If a backout lands as a `git revert` of the offending commit(s) I'm 
>> certainly less concerned, as that's annoying but not impossible for people 
>> to continue rebasing against.
> 
> Right, that's how backouts land.

I'm still a bit worried about this unless the revert rate comes down pretty 
significantly for any shared branch between servo and gecko. According to what 
jgraham pointed me at on IRC (futurama.theautomatedtester.co.uk), it's not 
uncommon to have multiple backouts per day. We already lose contributors to 
Servo because they can't handle the hurdle of rebasing against a revert-free 
tree, and the idea of having people deal with rebasing over a commit, over its 
backout, and then back over it landing again has me a bit scared. We already 
rely on "jdm-carry" far too often.

But we'll see how the proposals come out. The last I heard, we would be 
co-landing servo bits to the autolander branch, which was intended to be mostly 
backout-free.

> No, absolutely not.  Backouts due to test failure are done as an `hg revert`. 
>  Sounds like something here got miscommunicated.  :)

This was probably my fault - identical words mapped to completely different 
things in git world versus mercurial world, and I should have attempted to 
clarify. Thanks for catching and drilling into this!
- Lars
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox

[Lars Bergstrom]

On Jun 20, 2016, at 9:25 PM, Boris Zbarsky <bzbar...@mit.edu> wrote:
> 
> On 6/20/16 8:35 PM, Lars Bergstrom wrote:
>> Backouts came up in the discussion, and I tried to make it pretty clear that 
>> they are not compatible with a GitHub-style development model (even if you 
>> *could* hypothetically do crazy things like force-pushing rewritten 
>> histories to master).
> 
> Wait, why are rewritten histories relevant?  A backout doesn't involve 
> rewriting history...

If a backout lands as a `git revert` of the offending commit(s) I'm certainly 
less concerned, as that's annoying but not impossible for people to continue 
rebasing against.

The way it was explained to me (and I may have been misunderstanding!) is that 
if a batch of changes land on m-i but then fail tests, they are removed and 
there is the mercurial equivalent of a force-push back to m-i without those 
changes in the history. That workflow made me concerned for people with an open 
PR, as if the PR was based on master at commit A, commit B lands and they 
rebase against it, but then B disappears from the history, getting their PR 
landable again is likely going to require intervention by a git expert.
- Lars
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox

[Lars Bergstrom]

On Jun 20, 2016, at 5:18 PM, Jack Moffitt  wrote:
> 
> I think the idea was that Servo code won't land until post-commit
> Gecko tests pass? Otherwise I'm not sure what we do about Gecko side
> backouts.

The last thing I was told is that we would be landing Servo commits to a branch 
that is *never* backed out. So, that would either be directly into m-c or into 
an autolander branch that is always directly merged into m-c by sheriffs at 
some point.

Backouts came up in the discussion, and I tried to make it pretty clear that 
they are not compatible with a GitHub-style development model (even if you 
*could* hypothetically do crazy things like force-pushing rewritten histories 
to master). It would definitely break the Servo contributor experience if the 
default PR rebasing workflow became unreliable.
- Lars
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Proposed work for upcoming sharing of Servo components with Firefox

[Lars Bergstrom]

As many of you may have seen from the document
(https://docs.google.com/document/d/1uubYE7JXaVY10PoAY9BVx8A-T11ZxP1RYqNOrFJwdcU/edit)
and discussions on dev-build and at the workweek, we have an
increasing desire to be able to try to develop and potentially ship
Servo code in Firefox. While this is exciting (yay, customers! yay,
faster Firefox!), it also means that we're going to be subject to some
growing pains as we around the requirements of our largest and best
customer.

We'd like to hear your comments here (or privately, if you prefer)
about these proposed changes. We're trying to figure out all of the
details, so now is the right time to bring up objections or
requirements!

1) Move our CI testing for servo/servo off of buildbot and into releng.

In order to ensure Servo changes do not break Firefox and vice-versa,
we are proposing unifying our autolanders and moving Servo's tests (as
Tier 1 - must pass to commit!) into releng. This would also mean
running relevant Firefox tests against Servo.

2) Move webrender and webrender_traits back into the Servo repository.

Because WebRender and Stylo are the two biggest projects that will
need to be worked on in a cross-cutting way across Firefox and Servo,
we'd like to have them out of a separate GitHub repo (with its "update
version, PR, cargo publish, pull down, repeat" workflow) and in the
one that is being tested and co-landed with Firefox. We plan to push
webrender to crates.io to ensure it is still separately usable by
other projects.

3) Get Stylo and WebRender onto stable Rust.

It is the intention to ship Rust code in Firefox using only stable
Rust features. That's not a hard requirement, but it means trying to
either stabilize features or rip out any unstable/nightly-only
features in use in either the Stylo or WebRender dependency graphs.

Please provide feedback on these topics or any others that come to
mind around these changes! Many of us across the company will be
working hard in the coming weeks to get a concrete proposal and
timelines in place for this work, so please reach out with your
concerns ASAP.

Thanks!
- Lars
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Editing the wiki now requires collaborator access

[Lars Bergstrom]

After removing a random thing added to our official Planning Roadmap
yet again, I've decided to make our wiki
(https://github.com/mozilla/servo/wiki/) editable only by
collaborators. So, as with labeling issues, anybody who edits these
pages needs to be in the Developers group in the Servo GitHub
organization.

If there are individual pages that you feel need to be more widely
editable, please bring them up and we can figure out a different place
for them to live (e.g., in-tree).

Thanks,
- Lars
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Proposal: cancel the weekly meeting

[Lars Bergstrom]

Valentin,

Will do! Do you think that a link to
http://statusupdates.dev.mozaws.net/project/servo (which is where we
all put our status updates - it's what our management follows
internally) is good, or would you like some more manual roll-up of the
work people did each week?

As for where the project's heading, I'll also make sure to add the
links to our quarterly planning from the weekly meeting minutes. Those
links include both our high-level planning and the specific quarterly
goals for the team and the collaborators with more dedicated time
(today, our most active volunteers and folks on partial loan from
other places in Mozilla).
- Lars

On Mon, Apr 18, 2016 at 6:02 AM, Valentin Gosu <valentin.g...@gmail.com> wrote:
> Reading the meeting notes has been quite interesting for me.
> While "This week in Servo" is also really useful for finding out what landed
> recently, it would be great to know about what the Servo team is currently
> working on, and where the project is heading. Maybe we could add this to the
> weekly report?
>
> Thanks!
>
> On 18 April 2016 at 07:38, Jack Moffitt <j...@metajack.im> wrote:
>>
>> I hear no objections, so I'm canceling the standing meeting.
>>
>> jack.
>>
>> On Sun, Apr 17, 2016 at 11:31 AM, Lars Bergstrom <larsb...@mozilla.com>
>> wrote:
>> > On Thu, Apr 14, 2016 at 2:46 PM, Manish Goregaokar
>> > <manishsm...@gmail.com> wrote:
>> >>
>> >> So yeah, +1 for cancelling. I do look forward to the meetings, since
>> >> they
>> >> give a nice overview of what's going on,
>> >> but TWiS should be capable of filling in that gap and the meetings
>> >> aren't
>> >> happening anyway.
>> >
>> > At this point, we have one on-thread vote for cancelling, several
>> > votes via IRC to cancel the meeting, and *zero* votes to keep it.
>> > Speak now, or prepare to have an hour per week freed from your
>> > calendars...
>> > - Lars
>> > ___
>> > dev-servo mailing list
>> > dev-servo@lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-servo
>> ___
>> dev-servo mailing list
>> dev-servo@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-servo
>
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Proposal: cancel the weekly meeting

[Lars Bergstrom]

On Thu, Apr 14, 2016 at 2:46 PM, Manish Goregaokar
 wrote:
>
> So yeah, +1 for cancelling. I do look forward to the meetings, since they
> give a nice overview of what's going on,
> but TWiS should be capable of filling in that gap and the meetings aren't
> happening anyway.

At this point, we have one on-thread vote for cancelling, several
votes via IRC to cancel the meeting, and *zero* votes to keep it.
Speak now, or prepare to have an hour per week freed from your
calendars...
- Lars
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Meeting notes from chat with the Devtools team

[Lars Bergstrom]

We talked about:
- Short and long-term plans for devtools protocol implementations
- Devtools.html UI
- Privileged JS
- Supervisory JS
- Architecture-related stuff
- Some longer-team feature ideas

https://github.com/servo/servo/wiki/Meeting-Devtools-Servo-2
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Proposal: cancel the weekly meeting

[Lars Bergstrom]

I'd like to propose that we cancel the weekly meetings and move the
discussions to an asynchronous medium (mailing list or GitHub Issues,
as appropriate).

As the project has matured and the team has grown, the weekly meeting
has become less useful. We can't (and shouldn't!) make decisions there
because neither the full team nor collaborators from the Gecko side
have an opportunity to comment, and that's been reflected in the fact
that we've either cancelled or basically had "status updates" in our
last few months of meetings. Our current alternating meeting schedule
also has no meeting time that is friendly to China Standard Time,
which is a bit inconvenient as we attempt to grow the team.

Where a face-to-face meeting is needed, I'd much rather schedule it
ad-hoc for a convenient time for the subset of people who need to
attend them.

Opinions?
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Please don't leave PRs without an assignee

[Lars Bergstrom]

I think that it would be nice if our highfive had the feature that
Rust's does (IIRC) where it can assign a reviewer based on area of
interest.

If you're referring to the governance list on the wiki
(https://github.com/servo/servo/wiki/Governance#super-reviewers), it's
not outdated, but just a different thing. Super reviewers are the
people who should be involved if there is a substantial design change
proposed for an area.
- Lars


On Wed, Mar 9, 2016 at 12:23 PM, Keith Yeung  wrote:
> Should we have a list of people who are familiar with a certain crate
> within Servo? I think the wiki has a list, but it seems oudated.
> On Mar 9, 2016 11:16 AM, "Jack Moffitt"  wrote:
>
>> On Wed, Mar 9, 2016 at 8:25 AM, Josh Matthews 
>> wrote:
>> > Hi reviewers of Servo! As you've noticed, we recently started assigning
>> > reviewers to new PRs by random selection. Sometimes this means that a
>> > reviewer ends up assigned to a PR which they don't feel comfortable
>> > reviewing, which is totally fine! When that happens, please redirect the
>> > review to somebody else more appropriate rather than just removing
>> yourself
>> > as the assignee.
>>
>> I would also encourage those of you getting PRs outside your comfort
>> zone to at least glance at the PR and maybe try and do what you can.
>> You'll learn something new, expand your comfort zone, and probably
>> catch some things other reviewers didn't. I often find that when I
>> review code I'm not as comfortable with, I'm usually much more careful
>> and catch more undocumented assumptions.
>>
>> jack.
>> ___
>> dev-servo mailing list
>> dev-servo@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-servo
>>
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] PSA: incoming Windows CI (AppVeyor)

[Lars Bergstrom]

We are in the process of enabling Windows CI on the main Servo
repository. We're using Homu + AppVeyor (http://appveyor.com/) to do
the testing, in a similar manner to how we use Homu + Travis on other
repositories. Current Linux and Mac builds will still be performed on
our BuildBot configuration. Status and failures for Windows should be
reported into the PR as usual.

We have a Professional AppVeyor subscription with additional
concurrent builders being enabled. The build times are shorter than
our long-pole CI, and we can add more concurrent builders if enabling
this has an impact on our PR landing times.

If you need to test a build on an AppVeyor instance and do not have a
Windows VM, There is a really neat trick for allowing you to RDP
(Microsoft Remote Desktop) into a worker by editing the appveyor.yml
file in your PR branch:
http://www.appveyor.com/docs/how-to/rdp-to-build-worker

Many thanks to Vlad for doing the initial Windows porting work, Manish
for his work on the CI bits, and Jayflux, uk992, frewsxcv, and many
others for additional debugging on the Windows builds themselves!
- Lars
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Fwd: Re: Suggested code review workflow

[Lars Bergstrom]

This may also be less of a big deal here at Mozilla, where there's
(presumably?) only been one bug database since 1998 and will only be
one forever, but when I was at MS, I had to make accessibility fixes
in some code that was a bit more than 20 years old, and "fixes
B1#2003" is really tough to track down, when the bug database for B1
has long been retired and everybody who worked on it is either retired
or Bill Gates (he wasn't retired yet).

At least in Servo, I could certainly see a world where we move off of
GitHub Issues some day, and telling people, "oh, you need to go to
larsberg's git mirror of the old issues repo and use his hacked-up web
frontend to look for the bug, but remember to subtract 1024, because
he couldn't build nice UI..." is bad.

So, just based on old battle wounds, I guess I'm more in the camp
putting justification for a piece of code near the code itself, with a
bug link mainly if there's some lengthy historical baggage, a comment
thread that captures an old architecture war, etc.
- Lars


On Sat, Feb 20, 2016 at 6:02 PM, Boris Zbarsky  wrote:
> On 2/20/16 5:10 PM, Josh Matthews wrote:
>>
>> (as a random comment, I never read multiline comments for Gecko. Only the
>> first line + the bug number. It is the bug where the relevant information
>> needs to be available. Whether it it available also elsewhere is less
>> important, IMHO.)
>
>
> Having the info in a bug is nice, but having to read 30, or 150, or 500 bug
> comments to find it can be less nice...
>
> I think Gecko tends to rely to much on the "it's in the bug" crutch and not
> put enough info into the commit message, personally.
>
> -Boris
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Please comment on your reviewable.io perf issues!

[Lars Bergstrom]

For the people doing lots of reviews in reviewable.io,

Please comment in https://github.com/Reviewable/Reviewable/issues/251
(or create new issues) on your performance scenarios when reviewing
large diffs. I personally like to load the whole thing, scroll
through, and be able to use search within the browser, which requires
full expansion. Please feel free to comment on your own experiences
with large reviews and scenarios that aren't as good as you'd like!

I've been talking with the maintainer, and he's very open to
continuing to improve our experience with large reviews in Firefox.

Thanks,
- Lars
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Using Cargo in Gecko

[Lars Bergstrom]

Thanks for doing this investigation, Valentin!

I'm a little bit worried about the mechanics of auto-upstreaming:
- How do we handle commit access? Having the upstream maintainers
(none of whom might be current Gecko peers) correctly identified and
doing reviews in bugzilla to ensure m-c pushes can be upstreamed seems
challenging.
- What about conflicts? If even half of Servo's dependency graph is
pulled in, that will be ~30 different repos, and the odds that some of
them will temporarily be incompatible with others means that a m-c
commit may be against an older version of upstream and not able to be
automatically upstreamed into master. Does everything vendored in m-c
get a private fork in the mozilla GH organization and get code and
policy conflicts resolved there?
- As I've heard it from the cargo team, this approach is different
from the solutions being pursued by the other nontrivial (>= 5 million
LOC) corporate build systems. I worry a bit about having a different
tool stack than the rest of the ecosystem and potentially confusing
volunteers who would like to contribute to Rust code in Gecko or have
their projects used in Gecko.

That said, trying to figure out how to make the obvious extension of
the current experience (set a `paths` override in a config file, clone
the repo, do the work there, open a PR and land upstream and push to
crates.io, remove the override, run the "vendor into m-c" tool to pull
it down, and *finally* land in m-c) seems brutal even for a single
dependency, much less something that sweeps across several of them.

The answer to any approach we come up with is probably "more tooling,"
but I suspect that, like bholley said below, there's a lot of
discussion to be had here around the myriad issues.

This conversation is also going on in Bugzilla here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1231764 and also has
build peers and Cargo folks in the discussion. I believe they're not
on dev-servo.
- Lars


On Thu, Dec 17, 2015 at 5:28 PM, Bobby Holley  wrote:
> I had a long conversation about the two-way sync stuff at Orlando with Alex
> and some of the Servo folks.
>
> We concluded that, long-term, we need to let Gecko hackers commit to the
> vendored code and have that code automatically upstreamed. Similarly,
> upstream fixes need to be automatically merged into Gecko.
>
> Everyone seemed on board with this plan, but Alex suggested that it should
> probably be a separate tool, distinct from Cargo. This tooling is going to
> be pretty important, but we should probably wait on it until we've got the
> other issues sorted out.
>
> bholley
>
> On Thu, Dec 17, 2015 at 3:04 PM, Valentin Gosu 
> wrote:
>
>> Hi folks,
>>
>> I just wanted to share some notes on using Cargo in Gecko. One of the
>> requirements was vendoring packages in tree. It turns out I was able to do
>> that with a .cargo/config file in the scope of the rust directory, which
>> defines the paths for dependencies, and [http] timeout = 0, which prevents
>> downloading any resources from crates.io. [1]
>> Better support for this use case would be welcome, such as making sure no
>> network connections are made (the index still gets refreshed), but this is
>> good enough for what we need at the moment.
>>
>> I'm not sure if we've agreed to have a top level directory for all of the
>> rust crates, but I think it makes sense. It allows for easier sharing of
>> crates (between necko and media for example).
>> From what I understand servo's mach has a command for two-way sync between
>> web-platform-tests and upstream. This would be a nice feature for cargo, as
>> most of our dependencies would come from crates.io. So identifying the
>> upstream repo, and doing a diff would be super awesome - probably for other
>> projects as well.
>>
>> I'll probably have more to share once/if I manage to use cargo withing
>> Gecko's build system.
>>
>> Thanks!
>>
>> [1] https://github.com/rust-lang/cargo/issues/1926
>> ___
>> dev-servo mailing list
>> dev-servo@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-servo
>>
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Meeting Nov. 30 (Mozlando topics; NCSU; crate squatting issues; PR queue)

[Lars Bergstrom]

https://github.com/servo/servo/wiki/Meeting-2015-11-30
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Rust upgrade landed!

[Lars Bergstrom]

After several weeks of grueling work by several people (including
Manish, Simon, Matt, and many  others, *especially* on projects where
we are not maintainers) to push through all of the necessary  updates
to dependencies, the Servo Rust upgrade has landed!

This upgrade is a major shift for Servo, in that we no longer build
our own Rust compiler snapshots but get our cross-compiler support by
assembling the per-target pieces that were broken out of the official
Rust nightlies by Emily, Brian, and Alex.

So, Rust upgrades no longer require an "ask larsberg to make a snap"
step! As described on the updated wiki page
(https://github.com/servo/servo/wiki/Updating-the-Rust-compiler-used-by-Servo),
all you need to do is update the `rust-snapshot-hash` file with the
new date and then push through any other changes as required. This has
two added bonuses:
- We just support all of the normal Rust host platforms out of box
with no additional work
- It should be much easier to layer in other cross-compiler targets
(e.g., `arm-linux-gnueabihf`) by simply downloading additional
cross-target libs instead of having to build a whole snapshot

Of course, we still support the usual "Bring Your Own Rust" by editing
`.servobuild`.

Thanks to everybody who stuck with this upgrade!
- Lars
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Weekly meeting (Intermittents; mailing lists vs. discourse; libc; E-Easy issues)

[Lars Bergstrom]

https://github.com/servo/servo/wiki/Meeting-2015-11-16
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] 2015/11/09 meeting (GitHub config; servo.org landing page; workflow; homu magic)

[Lars Bergstrom]

On Tue, Nov 10, 2015 at 5:30 AM, David Bruant  wrote:
> Google Spreadsheet has a nice feature that allows sharing by URL in a
> read-only fashion. More details here :
> https://support.google.com/drive/answer/2494822
> Section "Share a link to a file or a folder", then "Computer"
> (It's "Get shareable link" then "People with the link can view")

Thanks! I granted you access and added the link to the published
readonly version of the doc to the meeting notes.
- Lars
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Meeting notes 11/2 (review carry-over; test coverage; 2016 roadmap; rebase/autosquash; PR queue; debug logging; CSSWG reftests)

[Lars Bergstrom]

You can also see it here publicly:
https://docs.google.com/spreadsheets/d/1HYoEo5Vx9XuFWFh_1zGWtT-pvebNqspY-PqbUzh3y7Q/pubhtml

There's nothing private about it! I just gave up after a half an hour
trying to figure out "how do I share this google doc so that everyone
in Mozilla+a list of contributors can edit it, but the public can only
view it," so I have the editable link for internal use and the
"published" view for externals.

I'll add that link to the meeting notes - thanks for catching it!
- Lars


On Tue, Nov 3, 2015 at 5:21 AM, Manish Goregaokar  wrote:
> I believe that's the internal spreadsheet, not supposed to be public.
>
> The roadmap on the wiki exists
>
> -Manish Goregaokar
>
> On Tue, Nov 3, 2015 at 4:10 PM, Tetsuharu OHZEKI 
> wrote:
>
>> > 2016 Roadmap
>> >
>> https://docs.google.com/spreadsheets/d/1HYoEo5Vx9XuFWFh_1zGWtT-pvebNqspY-PqbUzh3y7Q/edit#gid=0
>>
>> I seem this document is not public for users who does not have a 'at
>> mozilla.org' account.
>> Could you change the permission?
>>
>>
>>
>> 2015-11-03 3:43 GMT+09:00 Josh Matthews :
>> > https://github.com/servo/servo/wiki/Meeting-2015-11-02
>> >
>> > cheers,
>> > Josh
>> > ___
>> > dev-servo mailing list
>> > dev-servo@lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-servo
>>
>>
>>
>> --
>> Tetsuharu OHZEKI
>> ___
>> dev-servo mailing list
>> dev-servo@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-servo
>>
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Meeting 2015-10-26 (WebRender; testing; ipc-channel on debug; bors try)

[Lars Bergstrom]

https://github.com/servo/servo/wiki/Meeting-2015-10-26
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Turning on autoloader rebasing and/or autosquashing

[Lars Bergstrom]

Two long-requested features have just been added by barosl to homu 
(https://github.com/barosl/homu/commit/d7ad33a1d4158fc78da4d86c6318a2f0fc1970cc 

 ): automatic rebasing and autosquash. I’d like to turn both on for the 
following reasons, but (at least from the conversations in #servo this 
morning), I’d love to hear arguments against.

- Automatic rebasing

Right now, our commit log history is somewhat mumbly-jumbly. The autolander 
adds a commit for the pull request detailing who reviewed it, etc., but the 
commit itself sits in the history wherever `master` was on the commiter’s local 
machine when they did the work. This makes looking at a given commit and 
figuring which PR it landed in require either some extra tooling or git-fu that 
most users don’t have.

- Autosquash

A huge tripping point for new contributors (and annoyance for longtime servo 
contributors) is going through the review process, pushing additional patches 
to the PR branch, and then at the end having to carefully rebase and squash 
each fixup commit into the appropriate place. It trips up new contributors 
because they have to use `git rebase`, and it annoys longtime contributors 
because you have to do the awkward “squash and r=me when that’s ready” loop. So 
long as we coach people to either put `fixup!` or use `git commit —fixup` when 
adding patches, the autolander would handle the squash automatically.

Opinions? Let the bikeshed begin!
- Lars


___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Meeting-2015-10-12 (mozlando, governance, review queue, reftests)

[Lars Bergstrom]

https://github.com/servo/servo/wiki/Meeting-2015-10-12
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Meeting notes 9/28 (Meeting time change; additional TWiS reporting; script crate rebuilds; webrender)

[Lars Bergstrom]

https://github.com/servo/servo/wiki/Meeting-2015-09-28
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Reviewers

[Lars Bergstrom]

On Sep 1, 2015, at 4:57 AM, James Graham  wrote:

On 01/09/15 12:29, Tetsuharu OHZEKI wrote:
>> Should we introduce some files which is like `OWNERS` file in Chromium
>> tree, or write a document to wiki?
> 
> If you want it in-tree — and that does have some advantages — it makes sense 
> to make it easily machine readable using an existing format. Can you add 
> arbitrary metadata to Cargo.toml files?

To date, I’d just been putting that information on our governance wiki page 
(https://github.com/servo/servo/wiki/Governance ).

My only concern with having it in-tree is if we can’t have the convention 
consistent across our dependencies, then tooling expecting to be able to find 
an owner has to have a reasonable fallback. That said, it’s probably still 
better than my strategy, which required a human to read a wiki page.
- Lars
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Meeting notes 8/17 (UA string updates; Android; profiling on ARM)

[Lars Bergstrom]

On Tue, Aug 18, 2015 at 5:13 AM, Gervase Markham g...@mozilla.org wrote:

 On 18/08/15 01:36, Lars Bergstrom wrote:
  https://github.com/servo/servo/wiki/Meeting-2015-08-17

 About the UA: if you find sites break because you are sending a UA and
 it sniffs you badly (e.g. sites using Enyo.js), I suggest _not_ trying
 to tweak the UA to make every site work. That way lies madness. Instead,
 hook servo or its harness up to our dynamic UA exception infrastructure
 that we have for B2G.


Definitely! Fabrice also suggested we look into that. We will probably
start by downloading the UA exceptions a first time, as we don't have any
support in Servo for background checking of new versions of itself or any
of the resources we'd like to be able to update. I suspect that support
will come sooner rather than later, though, as there's a lot of interest in
being able to stream down things like updates to our HTML browser UI or A/B
test different versions of it on different portions of our (currently
nonexistent...) user base.

Thanks!
- Lars
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Meeting notes 8/17 (UA string updates; Android; profiling on ARM)

[Lars Bergstrom]

https://github.com/servo/servo/wiki/Meeting-2015-08-17
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] mac3

[Lars Bergstrom]

I’d prefer that we only move things to nightly that will not cause a tree 
closure in the event of failure. e.g., performance tests, valgrind runs, 
fuzzing, etc.

If we also put CSS / layout tests or other things we decide are “too slow” onto 
nightly builders, we’ll have the worst of both worlds - you still have to wait 
through a CI queue to land a fix, but we can also have tree closures, need 
sheriffs, and have to back out patches. I dealt with that since the 90s and, 
like most things I lived through in the 90s, would prefer never to experience 
it again :-)

Up until now, we’ve managed with less than 1/10 of the hardware spend of the 
Rust team by carefully tweaking our infra. Now that our test and compile load 
is growing, we can use some of the budget (which we did allocate for 2015) to 
see if we can make it through 2015 until the TaskCluster folks get OSX support 
online and we can look to moving onto something a bit less ad-hoc than our 
massively redundant buildbot.

That said, we’re always going to be gated on the Rust compile, especially for 
release. While the 45 minute OSX build appears to be a hardware issue, even at 
20 minutes if we double the size of the Servo Rust codebase without reducing 
the sequential dependency chain and assume wistfully that Rust build times 
merely increase linearly with code size, we’re going to have a much bigger 
problem.

Sorry for the long queue times! The requirement to switch to release builds 
because of the need to optimize ipc-channels and the Cargo limitation around 
that (https://github.com/rust-lang/cargo/issues/1359) put us into this 
situation months before we’d been expecting to hit it.
- Lars

On Aug 7, 2015, at 5:52 AM, Manish Goregaokar manishsm...@gmail.com wrote:

I think we should be removing mac3 builds as well.

I'll repeat what I proposed in IRC: We can instead have a nightly set of
builds, for stuff like this which would be too much to run every build.
This can include testing release builds, mac3, and future valgrind/android
tests. If something breaks, we can bisect if necessary.

-Manish Goregaokar

On Fri, Aug 7, 2015 at 3:10 PM, Ms2ger ms2...@gmail.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hi all,
 
 The last mac3 run (http://build.servo.org/builders/mac3/builds/829)
 took 1 hrs, 13 mins, 57 secs, of which it spent 45 minutes compiling.
 As long as we have test-css running on linux (where css and wpt
 together don't make to 30 minutes), does it make sense to have this
 builder nearly double our turnaround time?
 
 Ms2ger
 -BEGIN PGP SIGNATURE-
 
 iQEcBAEBAgAGBQJVxH0KAAoJEOXgvIL+s8n2d2wH/RsgXBnAaZA1W4Jw6bTp0kqL
 pf0cl1Sjc56GK7vSd1C3BxnPqXFWuGJryuTJd7PuPElFfWiGBPlqp+ZRrsujVA23
 zQvKjR8SurGev3Q1tdNClVAiJo+mtLlVzHx6Vptk1SFzhl232MYWci+jMspTq8p6
 PNONLJ9B83SIRMAV5M9kvAQZKnw1yqthAEHd3OHPUKSyRxO5AX9kcPeKyLNvN+qK
 Te13YXa9TeWB/8hXo//t0yNs5YV72mJ8exaIEiSVA2zkvQUZArOO5YEj7NfkT3BK
 ugXNdyQLs/iQF8uiaaaqYmBThuiH6HJt09w8npvOYVE9hqvuuB0ir2SpLMS7NR4=
 =SALA
 -END PGP SIGNATURE-
 ___
 dev-servo mailing list
 dev-servo@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-servo
 
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Proposal: Close areas of the tree that are yet to be e10sified

[Lars Bergstrom]

What is left to land these patches, and whom do you need help from to get these 
finished?

I’m fine with freezing these interfaces if it’s for a week or so, but during 
the last few weeks this change has uncovered some pretty big holes in Cargo, 
the WPT tests, our CI configuration, etc. I guess I’m primarily curious if you 
have a sense for how long it will take to get this landed and whether there’s 
anything we or the Rust team can do to speed things along.
- Lars


On Jul 24, 2015, at 11:03 PM, Patrick Walton pwal...@mozilla.com wrote:

Oh, I forgot to mention 2D canvas and WebGL. This implies a moratorium on
all new canvas or WebGL functionality.

Patrick

On Fri, Jul 24, 2015 at 8:45 PM, Patrick Walton pwal...@mozilla.com wrote:

 As most people know by now, I'm having a lot of trouble getting
 multiprocess Servo landed :) Much of the trouble here is that changes keep
 coming in that are not multiprocess safe, and as multiprocess tends to
 trigger random test failures it ends up being a never-ending losing battle
 to keep up with the churn while simultaneously fixing test failures.
 
 I propose *freezing the interfaces* for the following sections of Servo
 until they have been made multiprocess-safe:
 
 * Developer tools
 * Core script/constellation communication: ScriptListener/ScriptControlChan
 * Pipeline and constellation setup
 * Image cache task
 * Resource task
 * Display list
 
 By freezing the interfaces I mean that no new channels (anything in
 `mpsc`) may be added, no more data types may be added that go over those
 channels, and no more variants in those enums (i.e. messages) may be added.
 
 Additionally, I would like to propose that any instance of boxed trait
 objects being sent over channels requires signoff that they are not
 crossing over a chrome-content boundary. If they are, I think they should
 be also blocked from landing until the relevant parts of Servo have been
 converted to be e10s-safe.
 
 I apologize if this seems heavy-handed, but it's been very difficult to
 land this stuff. I'm working around the clock to try to lift these
 restrictions, but I don't know how much longer it will take.
 
 Thoughts?
 Patrick
 
 
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Meeting notes 7/13 (ms2ger, surrogates in DOM, panics, IPC)

[Lars Bergstrom]

Thanks for the offer! I will coordinate with you and others who volunteered to 
handle other languages.
- Lars

On Jul 15, 2015, at 2:31 AM, Shing Lyu s...@mozilla.com wrote:

Hi all,

I just saw the meeting notes that you are planning to convert the training 
materials into blog posts. I would be happy to translate them into Traditional 
Chinese. (And perhaps also publish them in Mozilla Taipei's Chinese blog 
http://tech.mozilla.com.tw/)

Cheers,
Shing

2015-07-14 2:12 GMT+08:00 Lars Bergstrom larsb...@mozilla.com 
mailto:larsb...@mozilla.com:
https://github.com/servo/servo/wiki/Meeting-2015-07-13 
https://github.com/servo/servo/wiki/Meeting-2015-07-13
___
dev-servo mailing list
dev-servo@lists.mozilla.org mailto:dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo 
https://lists.mozilla.org/listinfo/dev-servo



-- 
Shing Lyu
QA, Mozilla Taipei

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Meeting notes 7/13 (ms2ger, surrogates in DOM, panics, IPC)

[Lars Bergstrom]

https://github.com/servo/servo/wiki/Meeting-2015-07-13
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Fwd: June 15 meeting notes (Whistler training; Research Assistants; SM upgrade; Servo multi-process)

[Lars Bergstrom]

Begin forwarded message:

From: Robert O'Callahan rob...@ocallahan.org
Subject: Re: [dev-servo] June 15 meeting notes (Whistler training; Research 
Assistants; SM upgrade; Servo multi-process)
Date: June 15, 2015 at 6:15:13 PM CDT
To: Lars Bergstrom larsb...@mozilla.com
Reply-To: rob...@ocallahan.org

 pcwalton: I think they're changing that? That's what I gathered from roc's 
 BlinkOn report.

I didn't discuss that at BlinkOn (changing Chrome for Android's GPU access), so 
no.

I like the idea of keeping GPU access outside sandboxed Servo content 
processes. We'll have to see how much of a win it is to put displaylists in 
shmem, since I seem to recall reading that kdbus shared mem is only a 
performance win for very large messages ( 512KB or something like that). But 
maybe we can do better.

Rob

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] June 15 meeting notes (Whistler training; Research Assistants; SM upgrade; Servo multi-process)

[Lars Bergstrom]

https://github.com/servo/servo/wiki/Meeting-2015-06-15
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Best way to work on multiple branches concurrently?

[Lars Bergstrom]

I personally keep the cargo dirs separate because Cargo doesn’t deal well with 
two concurrent runs, and I’m frequently developing and building in the two 
different clones at the same time. You *should* be able to share the rust/cargo 
snapshot directory without major concerns, though.

On Jun 10, 2015, at 3:02 PM, Manish Goregaokar manishsm...@gmail.com wrote:

Copy servobuild.example to .servobuild

Then just add the path of a central .cargo or .servo to the cache-dir and
cargo-home-dir keys.

Mine are ./../.servo and ./../.cargo

-Manish Goregaokar

On Thu, Jun 11, 2015 at 1:26 AM, Nicholas Nethercote n.netherc...@gmail.com
 wrote:

 Hi,
 
 I often like to work on multiple branches concurrently, to work around
 the fact that Servo builds are slow. The obvious way to do this is to
 just have multiple clones. That's what I do with Firefox (using
 Mercurial).
 
 I've read that git 2.5 will have a `git checkout --to=path` command
 which will support multiple working branches from a single repo
 directly. (See
 http://stackoverflow.com/questions/6270193/multiple-working-directories-with-git/30185564#30185564
 .)
 So that's nice.
 
 But for Servo there's the added complication of having a rustc and a
 .cargo/ directory. It'd be nice to avoid having to download rustc
 twice if both clones require the same version. It'd also be nice to
 avoid building all the code in the .cargo/ directory twice, at least
 (again) when the versions match up. IIRC there is a way to specify
 that the .cargo/ directory should go somewhere else (and indeed it
 used to go in $HOME by default), though I don't know what it is.
 
 Anyway, I'm just wondering how other people deal with this. Thanks.
 
 Nick
 ___
 dev-servo mailing list
 dev-servo@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-servo
 
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] June 8 meeting notes (Friend of the Tree; Whistler training; rust-geom; Cargo; graphics APIs)

[Lars Bergstrom]

https://github.com/servo/servo/wiki/Meeting-2015-06-08 
https://github.com/servo/servo/wiki/Meeting-2015-06-08
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Meeting notes 5/18 (Glutin, embedding, Whistler, RTL status)

[Lars Bergstrom]

https://github.com/servo/servo/wiki/Meeting-2015-05-18
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Tree frozen for rust upgrade

[Lars Bergstrom]

The Rust upgrade has landed! Thanks to everybody for jumping on the reviews and 
fixes so quickly so that we could land it and reopen the tree.
- Lars

On May 4, 2015, at 2:24 PM, Lars Bergstrom larsb...@mozilla.com wrote:

The tree is now frozen pending landing the current Rust upgrade, which will 
bring us to: 
https://github.com/rust-lang/rust/commit/551a7484cf01440ee84148ebd18bc68bd7c8
 
https://github.com/rust-lang/rust/commit/551a7484cf01440ee84148ebd18bc68bd7c8,
 just 5 days ago :-)

Please feel free to review relevant pieces of the PR and let’s get this in!
https://github.com/servo/servo/pull/5935 
https://github.com/servo/servo/pull/5935

Thanks for everybody’s help (including *many* fixes and workaround from the 
Rust team) on this one!
- Lars

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Tree frozen for rust upgrade

[Lars Bergstrom]

The tree is now frozen pending landing the current Rust upgrade, which will 
bring us to: 
https://github.com/rust-lang/rust/commit/551a7484cf01440ee84148ebd18bc68bd7c8
 
https://github.com/rust-lang/rust/commit/551a7484cf01440ee84148ebd18bc68bd7c8,
 just 5 days ago :-)

Please feel free to review relevant pieces of the PR and let’s get this in!
https://github.com/servo/servo/pull/5935 
https://github.com/servo/servo/pull/5935

Thanks for everybody’s help (including *many* fixes and workaround from the 
Rust team) on this one!
- Lars
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Testing Reviewable for reviews

[Lars Bergstrom]

As was mentioned briefly in the meeting notes for this week 
(https://github.com/servo/servo/wiki/Meeting-2015-04-13 
https://github.com/servo/servo/wiki/Meeting-2015-04-13 ), we are trying a new 
service, http://reviewable.io http://reviewable.io/, for performing our 
reviews. This week, please make an effort to try out the tool for your reviews 
by clicking on the large purple “review on reviewable” link in the PR and let 
me know either via e-mail or IRC what you do and don’t like about it. 
Comparisons to either Critic or the built-in GitHub review UI are welcome.

I’m trying this out because:
- It handles rebases / force-pushes to PR branches automatically (easily our #1 
Critic failure point, especially for new contributors).
- The comments show up on GitHub  GitHub comments show up there, so there’s no 
“two worlds” experience.
- I only need to feel guilty for begging jgraham to help with our Web Platform 
Tests integration, and not both that AND our twice-weekly Critic crises.

Thanks,
- Lars

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Servo team Q2 projects

[Lars Bergstrom]

Here are some ideas we've been talking about on my team:

- Figure out CSS WG reftest integration.
Right now, there's a python/mercurial build process that turns XHTML files into 
HTML to run them and it's not clear how to either integrate that without a 
giant mess (even by servo build standards!) or upstream work we do. I'd like to 
sort this out so we can have a test experience for layout tests that's similar 
to that of the DOM / WPT tests, especially for E-Easy bugs.

- Perf testing for some basic scenarios along with reporting.
Anything we make an explicit perf goal for this quarter (such as the 
interactions/gestures/network/graphics you mention below) I'd like to have some 
sort of test for (unless it's just for a one-off demo). Rust upgrades tend to 
regress our performance work otherwise.

- Emulator-based testing for Android  Gonk
Just a basic page load to ensure there aren't things like the OpenSSL library 
loading bugs, especially now that there's an Android nightly APK up there :-)

- Critical features blocking many pages
Need that flexbox. There were some scheduling snafus with it this quarter, but 
I think we need to be working on it in Q2 just to be able to build or view more 
pages, even if much of the team is working on perf/bugfixing.
html5ever is going to need document.write for many pages to work.

- SM Upgrade
I'd also like to do whatever we can to support jdm with his pending 
SpiderMonkey upgrade, maybe even treating it like a rustup.
- Lars

On Mar 18, 2015, at 12:15 PM, Jack Moffitt j...@metajack.im wrote:

It's about time to start planning and setting goals for Q2, and as I
mentioned in this week's meeting, I think focusing on usability and
performance tasks would be appropriate. I assume that a few people
will keep pushing features forward this quarter, especially as there
are several multi-quarter projects in flight, but the idea is that
most of our effort will be directed to usability and performance.

Here is an (unordered) list of possible projects:

- Implement CSS 3D transforms and make the CSS FPS
(http://keithclark.co.uk/labs/css-fps/) run at full speed. This could
be a compelling demo since other browsers fare poorly. Another example
of this is
- Get jQuery's test suite passing in Servo
- Get React working in Servo
- Find and fix bugs relating to extra reflows and incremental layout
- Get multiple resource loading working well enough that page load
times are competitive
- Implement the Timeline debugging protocol so that we can get
timeline reports from Firefox debug tools for Servo
- Get basic interactions and gestures polished: scroll performance on
Linux, OS X, and Android; pinch zoom; interactive window resizing; etc
- Create compelling demos that benefit from Servo performance or tech
and satisfy real user needs. Example: Patrick has been working on a
text-zoom demo that very fast in Servo and not great elsewhere; it is
a solve real user problems on mobile devices.
- Tune performance in networking and graphics.
- Polish the new HTML-based browser shell (landing soon) and get it
working well on all platforms
- Find slow interaction patterns and make them fast. Examples: Twitter
infinite scroll is janky in other browsers; an isolated demo of this
would make a good first dynamic test suite addition. Make them smooth
in Servo.

There are probably some layout and other bugs that need addressing
too. The iframe and constellation refactoring that happened in Q1 is a
good example of that kind of work.

I'd love to hear what other ideas people have as well.

jack.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Servo team Q2 projects

[Lars Bergstrom]

We've committed to an alpha release by the end of the calendar year :-)

We have an Android APK being built and published nightly, but I wouldn't want 
to point people at it until we have more testing around that build, an upgraded 
SpiderMonkey, and do some of the work on networking and resource loading that 
Jack mentioned below. If things go well, that would hopefully be sometime in Q3.
- Lars


On Mar 18, 2015, at 12:21 PM, Tetsuharu OHZEKI saneyuki.s...@gmail.com wrote:

 I'd love to hear what other ideas people have as well.

- how about async DOM APIs (including GlobalFetch)?
- And will publishing dogfooding release be targeted in Q3~Q4?


2015-03-19 2:15 GMT+09:00 Jack Moffitt j...@metajack.im:
 It's about time to start planning and setting goals for Q2, and as I
 mentioned in this week's meeting, I think focusing on usability and
 performance tasks would be appropriate. I assume that a few people
 will keep pushing features forward this quarter, especially as there
 are several multi-quarter projects in flight, but the idea is that
 most of our effort will be directed to usability and performance.
 
 Here is an (unordered) list of possible projects:
 
 - Implement CSS 3D transforms and make the CSS FPS
 (http://keithclark.co.uk/labs/css-fps/) run at full speed. This could
 be a compelling demo since other browsers fare poorly. Another example
 of this is
 - Get jQuery's test suite passing in Servo
 - Get React working in Servo
 - Find and fix bugs relating to extra reflows and incremental layout
 - Get multiple resource loading working well enough that page load
 times are competitive
 - Implement the Timeline debugging protocol so that we can get
 timeline reports from Firefox debug tools for Servo
 - Get basic interactions and gestures polished: scroll performance on
 Linux, OS X, and Android; pinch zoom; interactive window resizing; etc
 - Create compelling demos that benefit from Servo performance or tech
 and satisfy real user needs. Example: Patrick has been working on a
 text-zoom demo that very fast in Servo and not great elsewhere; it is
 a solve real user problems on mobile devices.
 - Tune performance in networking and graphics.
 - Polish the new HTML-based browser shell (landing soon) and get it
 working well on all platforms
 - Find slow interaction patterns and make them fast. Examples: Twitter
 infinite scroll is janky in other browsers; an isolated demo of this
 would make a good first dynamic test suite addition. Make them smooth
 in Servo.
 
 There are probably some layout and other bugs that need addressing
 too. The iframe and constellation refactoring that happened in Q1 is a
 good example of that kind of work.
 
 I'd love to hear what other ideas people have as well.
 
 jack.
 ___
 dev-servo mailing list
 dev-servo@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-servo



-- 
Tetsuharu OHZEKI
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Build flavors and defaults

[Lars Bergstrom]

Two questions about build flavors.

1) Should we change the default build type back from debug to release?

When we made the switch to cargo, we changed to debug builds by default, which 
made for some good “reduced build times” headlines, but has gotten me mail from 
externals evaluating Servo asking why it’s so slow/choppy. It has also tripped 
up internal folks doing performance or memory profiling more than once.

2) Should the builders test release only or release and debug?

We had release-only regressions during the last set of Rust and submodule 
upgrades, which is really bad (e.g., right now, Servo release on OSX does not 
display any content!). The only question in my mind here is whether we want to 
test everything in release+debug, just test release, or mainly test release but 
have a token debug build/test machine.

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] PRs are now gated on building on gonk

[Lars Bergstrom]

In addition to testing on Linux and OSX plus building from Linux targeting 
Android, we will now gate Servo PRs on also building on Linux targeting Gonk.

Thanks to the initial work by Michael Wu and some great follow-up work by 
Manish, we now have pretty well-automated builds of Servo targeting Gonk 
(“b2s”), though (like Android) we still have some Rust/Cargo bugs with OSX 
cross compilation, so it’s Linux-only for now. Instructions on how to build and 
run it are at:
https://github.com/servo/servo/blob/master/ports/gonk/README.md 
https://github.com/servo/servo/blob/master/ports/gonk/README.md

Pending some quick administrative checks, we will try to make a “mach 
boostrap-b2g” command similar to our other bootstrap commands so that people 
don’t have to have a flame device attached and then enlist in + build all of 
b2g.

Thanks to Michael and Manish for pulling together this support, and hopefully 
now that we’ll keep it building others will be able to more easily experiment 
with this target!
- Lars
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Tree is closed to land the Rust upgrade

[Lars Bergstrom]

The Rust upgrade has now landed and the tree is reopened. Thanks to everybody 
who helped finish it off and for your patience while the tree was closed!

Let’s review some PRs - 
https://github.com/servo/servo/labels/S-awaiting%20review 
https://github.com/servo/servo/labels/S-awaiting%20review :-)
- Lars

On Feb 10, 2015, at 9:34 PM, Lars Bergstrom larsb...@mozilla.com wrote:

Please do not r+ any more patches until this Rust upgrade has landed! We are 
very close, with just a bit of code left to review and a small issue to address:
https://github.com/servo/servo/pull/4893 
https://github.com/servo/servo/pull/4893

Thanks,
- Lars

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Tree is closed to land the Rust upgrade

[Lars Bergstrom]

Please do not r+ any more patches until this Rust upgrade has landed! We are 
very close, with just a bit of code left to review and a small issue to address:
https://github.com/servo/servo/pull/4893 
https://github.com/servo/servo/pull/4893

Thanks,
- Lars
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] NCSU project brainstorming

[Lars Bergstrom]

In a tweet here: https://twitter.com/annevk/status/557086893402521600
There's a recommendation that a browser play around with letting XHR trigger 
busy indicators:
https://github.com/whatwg/fetch/issues/19

I like the idea of also having some projects that experiment with new (small) 
potential web platform features!

On Jan 17, 2015, at 9:55 AM, Josh Matthews j...@joshmatthews.net wrote:

Following the general success of last term, I've been asked if Servo can 
provide four more projects for a new batch of students to work on this term. 
Commence brainstorming!

Cheers,
Josh
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Cancellation of this week's Servo meeting

[Lars Bergstrom]

Mozilla’s US offices are closed today for the Martin Luther King, Jr. holiday, 
so we will not be having our Servo meeting this week.

See you all next week!
- Lars

Also, jdm, ms2ger, and others are making fantastic work going through the 
upgrade of Servo to Rust 1.0 alpha! If you would like to help, we are 
coordinating using the following etherpad: https://etherpad.mozilla.org/rustup
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] PSA: Rust upgrade landed

[Lars Bergstrom]

On Jan 8, 2015, at 9:50 AM, Ms2ger ms2...@gmail.com wrote:
 
 Thanks to all who helped!
 
 Be aware that you need to ./mach clean before building (symptom if you
 forget is rustc failing with
 
 task 'rustc' panicked at 'assertion failed: end = self.len()', 
 /home/larsberg/rust/src/libcore/slice.rs:432
 
 ).
 
 Next stop: 1.0!

Indeed, thanks both to everybody on the Servo team who pitched in at the last 
minute to land this and the swarm of folks from the Rust community who helped 
us track down a memory corruption issue exposed by this latest upgrade.

Our rough outline for the next few weeks in Servo is:
1) Finish reviewing and landing the outstanding PRs (especially pcwalton's CSS 
additions)
2) After Rust 1.0-alpha is released tomorrow, create a snapshot and begin the 
upgrade to it
3) Once we get somewhat close, lock the tree and focus on landing the upgrade

I and the Rust team expect this may be an early-2014-like upgrade, as there 
have been quite a few new features and major changes landed in the past month 
(our Rust build is from 12/12, with one additional cherry-pick compiler bugfix 
on top), not all of which have had time to stabilize. There will also be a 
large number of code changes required, so I apologize in advance for any 
possibly-lengthy tree freeze we have in order to reduce the upgrade branch 
rebase pain, particularly as we get close to finishing it.
- Lars
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Meeting notes from Mozlandia

[Lars Bergstrom]

Below are links to transcripts of our (very productive!) meetings with teams 
outside of Research during the Mozlandia workweek.

Meeting with the SpiderMonkey team:
https://github.com/servo/servo/wiki/Mozlandia-JS

Meeting with Build peers on landing Rust code in Gecko:
https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko

Meeting with B2G on B2S:
https://github.com/servo/servo/wiki/Mozlandia-B2S

Meeting with the ATeam on WPT:
https://github.com/servo/servo/wiki/Mozlandia-WPT

Meeting with the ATeam on automation:
https://github.com/servo/servo/wiki/Mozlandia-Automation

Meeting with the GFX team:
https://github.com/servo/servo/wiki/Mozlandia-gfx

In addition to these meetings, we also had some Servo mentoring sessions during 
the weeknights that helped us both bring up a few new contributors and have 
some more extended discussions.

Most exciting, though, was the work by Michael Wu on getting Servo running on 
top of Gonk on a Flame:
https://twitter.com/larsberg_/status/539937229049581568
By the end of the week, he had a port 
(https://github.com/servo/servo/pull/4206) that can not only browse, but also 
handles scroll and pinch-zoom touch events!
- Lars
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] PRs are now gated on the Android build

[Lars Bergstrom]

Thanks to some heroic dependency patching by Glenn and Matt last night / 
morning, Android is building again after the last Rust upgrade! Since our 
Android builder is also working (http://build.servo.org/waterfall 
http://build.servo.org/waterfall), I have changed the infrastructure to 
perform trial builds on Android as well and gate landing PRs on the build 
succeeding.

We do not yet perform tests of the resulting binary (and it does not yet work, 
due to https://github.com/servo/servo/issues/3988 
https://github.com/servo/servo/issues/3988), but we are looking into 
solutions that will ensure Android also keeps running, including just launching 
Servo on a test page in the emulator. Longer-term, we may use some of the new 
dedicated ARM servers from http://labs.online.net/ http://labs.online.net/, 
which are currently ARM Linux only, but the company is interested in 
potentially supporting ARM Android images as well.
- Lars
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Meeting-2014-09-08 (cargo; script compilation memory usage; blocking issues; android; sharegl; busy-waiting)

[Lars Bergstrom]

Meeting notes:
https://github.com/servo/servo/wiki/Meeting-2014-09-08

There was no meeting on September 1, as that was the US Labor Day holiday.

Some interesting PRs from the last two weeks:
- Glenn added initial layout debugging support: 
https://github.com/servo/servo/pull/3206
- Simon added sideways text: https://github.com/servo/servo/pull/3181
- Martin added typed units support to the compositor: 
https://github.com/servo/servo/pull/3173
- Laleh added the power usage measurement scripts she has been using to 
generate the graphs that appear in our LinuxCon, etc. presentations: 
https://github.com/servo/servo/pull/3167
- Glenn added https support: https://github.com/servo/servo/pull/3148

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Recent Improvements to Functions like getClientBoundingRect

[Lars Bergstrom]

On Aug 28, 2014, at 9:26 PM, Cameron Zwarich zwar...@mozilla.com wrote:

 On Aug 28, 2014, at 5:45 PM, Clark Gaebel cgae...@mozilla.com wrote:
 
 Running this on Firefox takes 500 ns/iteration. Chrome takes 700 
 ns/iteration.
 
 Servo before [1] lands took 8100 ns! That's paying a lot (some would say too 
 much) for a parallel architecture, when simple queries experience a 10x 
 slowdown.
 
 However, thanks to [1], Servo is down to 950 ns/iteration. This is very 
 competitive with Firefox and Chrome, especially when considering the mutex 
 involved. I'm sure with some micro-optimization work we can get closer.
 
 As a side point, why is there a 7 us overhead here for message-passing 
 between green threads? Is it really that bad? Are script and layout currently 
 green tasks, or did something land causing this to not be the case?

Yes, the current perf issue is a bug due to a workaround landed to move script 
onto a native task to avoid some bugs related to Servo's very-old SpiderMonkey 
but very-new Web Workers support:
https://github.com/servo/servo/pull/2842

That architecture will probably persist until we get a SpiderMonkey upgrade 
that will allow us to switch script back to also being on a green thread, per 
the discussion in this thread:
https://github.com/servo/servo/pull/2915#issuecomment-50355651

At that point, I'd expect script to layout calls via message passing to be much 
cheaper than a mutex acquisition, but would be very interested to see numbers 
comparing them!

In general, I'd be a little wary of adding global locks into Servo unless it's 
really necessary (i.e., if it turns out we can't architect away the race 
condition Cameron brought up in any other way). Since we haven't found a good 
way to do any concurrent protocol verification yet for Servo, it's really easy 
to end up writing deadlocky or racy code (mainly w.r.t. underlying native 
resource allocation/destruction). For example, I spent way too much time 
getting shutdown cleaned up so that we don't intermittently crash due to 
attempting to render to graphics contexts that had been destroyed too early, 
and that was just tracking through our spaghetti message passing code, with no 
locks to reason about.
- Lars

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Meeting notes: 7/14

[Lars Bergstrom]

https://github.com/mozilla/servo/wiki/Meeting-2014-07-14 (Android; contractor; 
coordinate spaces; 32-bit  Rust issue tracking; stack sizes; graphics; HTML; 
CI)

Thanks,
- Lars (filling in for jdm, who is out this week)
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Servo and Merging PRs with Travis CI

[Lars Bergstrom]

We recently moved our infrastructure to Travis CI in order to gain some 
flexibility (http://www.lars.com/servo/travis/2014/06/11/servo-travisci.html) 
and reduce our build time (clean builds have gone from hours to  10 minutes!). 
This e-mail describes some of the temporary and longer-term changes to how we 
merge PRs.

Once people rebase their existing PRs on top of the Travis CI support in 
master, the PRs will automatically be tested. The status of a PR will be shown 
as green ball=passsed tests, orange ball=in progress, x=failed. These will 
appear next to the PR number on the Servo PRs page: 
https://github.com/mozilla/servo/pulls

You can get additional details (or watch the log during the build and tests) by 
going to the Travis CI page for Servo: 
https://travis-ci.org/mozilla/servo/pull_requests

In the short term, when a PR is green and master has not been updated, instead 
of our previous r+ system, you may press the Merge Pull Request button. If 
the PR is green but master has changed since it was tested, please first go to 
the Travis CI page for Servo, find the corresponding build, and press the 
Restart Build button before merging to ensure that no conflicting changes 
have landed in master since the PR was tested.

You can tell whether a PR was built against master by finding the hash for 
master from https://github.com/mozilla/servo/commits/master and comparing it 
against the one listed in the test merge commit for the PR at 
https://travis-ci.org/mozilla/servo/pull_requests. Don't stress too much if you 
mess this up; Travis will report to #servo if we landed something in master 
that fails a test and we can back it out.

In the longer term, we will automate this process by rebuilding bors (We have 
the technology!) to perform the necessary check, possible rebuild, and the 
GitHub merge upon r+, as it previously did with our buildbot-based system.

If you have any questions, please feel free to track down larsberg on #servo.

Thanks,
- Lars
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] 2/3 meeting notes (various project status updates; display lists)

[Lars Bergstrom]

On Feb 8, 2014, at 2:11 AM, eh...@mytime.com wrote:

 I see this on the agenda:
 
 Handling github issues: create more E-Easy? And how should people 'claim' 
 them and get them 'fixed/closed'?
 
 It's not mentioned again though. I'd like to know about the claiming 
 process in particular. The last couple of times I started trying to implement 
 something in Servo, someone had started working on it unbeknownst to me. 
 That, combined with my major Rust noobishness has been a little demotivating.

I apologize for your bad experience trying to contribute a fix for a first 
issue! If you're looking for a straightforward first one, I just added one:
https://github.com/mozilla/servo/issues/1641

In the future, please comment in the issue first (just say, can I take 
this?). One of us will definitely respond quickly and the comment will 
hopefully serve as a warning to anyone else looking at it. It will also ensure 
that we comment on whether anything has changed with the issue, as the Servo 
codebase changes quickly.

One of our biggest challenges using GitHub (there are many - 
https://github.com/mozilla/servo/wiki/Github-challenges ) is that GitHub 
doesn't allow us to assign issues to non-members or for people to claim them 
easily. We also have a good problem that when we create approachable E-Easy 
issues, contributors fix them more rapidly than we can write them up.

We didn't get around to talking about the E-Easy issues in the meeting because 
we had pretty low attendance at the Servo meeting this week due to travel 
schedules and time zones of most of the core team members, so I didn't think it 
made a lot of sense for Patrick and I to just chat about it :-)

Thanks for your interest in Servo!
- Lars

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Event loop and compositor communication

[Lars Bergstrom]

 3. Attach the file descriptor for the compositor's end of the pipe to
 the compositor event loop, and eliminate the polling.
 
 Thus at the end of this, the renderer end of the Unix socket will be in
 `libuv` land, and the compositor end will be in the OS's native event loop.

I like the overall design of this proposal much better than what we were 
thinking of doing previously to address polling 
(https://github.com/mozilla/servo/issues/588 ).

Please correct me if I'm misunderstanding, but in this design we would still 
need to both receive Rust messages and process windowing messages in the 
compositor and on the same underlying OS thread (because of restrictions with 
touching windowing system objects from a non-UI/main thread). If so, then we'd 
have to do something to either unify those events or change the current code, 
with some obvious ideas being:
1) Have platform-specific code below the glfw/glut layer that has access to the 
raw UNIX X11 socket and pipe to call select on both / named pipe and window 
handle to call MsgWaitForMultipleObjectsEx on both / whatever you do on OSX.
2) Have two tasks, one waiting in windowing and one waiting on the pipe, with 
the ability for the pipe to wake the windowing thread so it knows to read a 
message queue via a hack windowing event ala the proposal in the issue above.
3) Change all of the code in the compositor that receives messages from the 
Renderer to be safe w.r.t. being called from a thread other than the OS thread.

Did you have other ideas on how to handle this? Or, am I misunderstanding this 
part of the design? Apologies if it's obvious and libuv handles this directly - 
I didn't see anything in the libuv documentation or example sources.

 Note that Google Chrome and Safari already do this (in Chrome's case, 
 with handwritten C++ code and a somewhat idiosyncratic event loop 
 abstraction). I don't expect our perf to be substantially worse.

Is the reason for the idiosyncratic event loop code related to combining the 
multi-platform windowing wait and waiting on the pipe?

Thanks for sharing this proposal,
- Lars
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] reg : Errors while building servo

[Lars Bergstrom]

After chatting on IRC with Myra and looking at the expanded logs, it appears 
that rustc is running out of memory. We'll try to work around that.
- Lars

On Oct 19, 2013, at 11:22 PM, supraja reddy supraj...@hotmail.com wrote:

 Hello everyone ,
 
 I was trying to build servo on my system when I encountered this problem 
 
 When I run the command :
 
 make  make check
 
 It pops this error :
 
 .
 .
 compile_and_link: 
 x86_64-unknown-linux-gnu/stage1/lib/rustc/x86_64-unknown-linux-gnu/lib/librustc.so
 error: internal compiler error: unexpected failure
 note: the compiler hit an unexpected failure path. this is a bug
 note: try running with RUST_LOG=rustc=1 to get further details and report the 
 results to github.com/mozilla/rust/issues
 make[1]: *** 
 [x86_64-unknown-linux-gnu/stage1/lib/rustc/x86_64-unknown-linux-gnu/lib/librustc.so]
  Error 101
 
 Can somebody help me with this .
 
 Thank you,
 
 Myra 
 
 ___
 dev-servo mailing list
 dev-servo@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-servo

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] tasks in servo did not run concurrently

[Lars Bergstrom]

All tasks should not be scheduled to run on the main thread: only the toplevel 
one where the compositor runs. That design ensures the windowing system calls 
(via glut and glfw) are performed on same system thread where the window was 
created and the windowing system was initialized, which is required by some 
windowing systems.

I wrote up a test that spawns a task that performs some work, printing 
concurrently with the top-level task that was started on the main thread and 
its output appears interleaved:
https://gist.github.com/larsbergstrom/6933164

How can I reproduce the behavior that you are seeing in servo? Where did you 
add tasks that do not have the behavior you were expecting? Is there a branch 
in your github repo that we can look at?

One possible issue I can imagine is that if the main thread started running 
another task due to the compositor thread sleeping, that task would block the 
compositor thread from running again because the compositor is bound to the 
main thread. But, when I last talked with Brian about that scenario, he 
mentioned that the main thread is normally not used by the Rust runtime and so 
the compositor should be the only task run on that system thread.

Thanks,
- Lars

On Oct 11, 2013, at 3:22 AM, 최영일 duddlf.c...@samsung.com wrote:

 
 Dear all,
 
 In order to test some parallel idea, I added a few tasks to layout task in 
 servo however I found that the tasks what I added did not run in 
 concurrently. they run with serialized. It looks to me that all tasks was 
 bounded at single thread and scheduled with std::rt::start_on_main_thread.
 
 I changed servo.rc not to be scheduled with std::rt::start_on_main_thread 
 like changing #[start] to #[main], removing std::rt::start_on_main_thread in 
 entry point of servo.rc and running compositing task in entry point to see 
 correct output in display then I found the tasks what I added run in 
 concurrently.
 
 Question is 
 - Is there any special reason that all tasks are scheduled in 
 std::rt::start_on_main_thread ?
 
 Regards,
 Young
 ___
 dev-servo mailing list
 dev-servo@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-servo

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] team meeting agenda bashing

[Lars Bergstrom]

That sounds like a great idea. Having only been around for a couple of weeks, 
the two things it sounded like people kept emphasizing as the key early tests 
for servo were:
- Greater speed on real benchmarks
- Quicker page load for sites like pintrest

So anything we can do that would demonstrate one of those seems like a very 
good use of the work week.
- Lars

On Aug 30, 2013, at 8:01 PM, Jack Moffitt j...@metajack.im wrote:

 I'm working on the agenda for the upcoming team meeting in Mountain View.
 
 What do people think about focusing our efforts getting some subset of
 Dromaeo working? I suspect this would involve implementing DOM APIs
 and measuring performance.
 
 It seems like an easy set of tasks to split up among everyone and by
 the end of the week we would have our first comparative numbers that
 aren't just microbenchmarks.
 
 jack.
 ___
 dev-servo mailing list
 dev-servo@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-servo

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo