> * we don't have an easy way to run single tests
run.py (in src/test/wpt) has an --include option. Be sure to source the
virtualenv in the build dir before running run.py
> * Servo times out on a lot of tests, causing the run to take 11 minutes here
We probably should exclude some of the t
g people run the entire check-wpt after every PR is a bit
unsustainable)
We probably should have bors output a diff of the metadata directory after
running the tests, which we can inspect for issues and then check in.
-Manish Goregaokar
On Sat, Apr 19, 2014 at 9:51 PM, James Graham wrote:
> On 1
This is great!
-Manish Goregaokar
On Sun, May 4, 2014 at 1:04 AM, Patrick Walton wrote:
> On 5/3/14 12:30 PM, Josh Matthews wrote:
>
>> Learn to love it. When you find a type error where something is asking
>> for a JSRef and you're not providing it, that's a pot
b.com/mozilla/servo/issues?labels=E-easy&page=1&state=open>
that
you can try once you have some familiarity with Rust. And #servo on IRC is
usually reasonably active if you need help.
-Manish Goregaokar
On Wed, May 14, 2014 at 3:27 PM, Ricardo Brandão wrote:
> Hi All,
>
> Yeste
should we do about our own http library?
- Thoughts in general?
(These can be discussed in the meeting, just putting this mail out with
most of the details in case I can't turn up)
Thanks,
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
brary -- I feel that this is
something the community does need at some point; but that's probably not
going to happen yet.
I'll probably get started on rust-fetch Sunday. Semester starts Monday,
progress might be a bit slow (fortunately cors.rs contains a lot of the
stuff I need fo
Sorry, the link is
https://github.com/Manishearth/rust-http/compare/chris-morgan:master...Manishearth:discombobulate
-Manish Goregaokar
On Sat, Jul 19, 2014 at 1:40 AM, Manish Goregaokar
wrote:
> Okay, so the past few days I've been playing around with rust-http. The
> main issue
which is a bit confusing.
-Manish Goregaokar
On Thu, Aug 7, 2014 at 6:26 PM, Simon Sapin wrote:
> Hi all,
>
> http://doc.servo.org/ is now live! It’s the rustdoc documentation for
> Servo master, including all submodules and Rust, at the specific versions
> that are being use
I'll have a look if I get time, then.
-Manish Goregaokar
On Thu, Aug 7, 2014 at 7:31 PM, Simon Sapin wrote:
> On 07/08/14 14:11, Manish Goregaokar wrote:
>
>> :D Love the docs, especially the bit about having the docs for our own
>> compiler version. I usually end up
A few days ago I was setting up a clean Rust build, and I wanted to avoid
the llvm build.
For some reason, the apt-get install from the Travis file didn't work --
there were gpg issues. Eventually I ended up using Servo's llvm snapshot.
Which was fine with me.
However, the only reason I knew that
This was supposed to go to rust-dev. Sorry about that.
-Manish Goregaokar
On Wed, Aug 27, 2014 at 11:51 PM, Manish Goregaokar
wrote:
> A few days ago I was setting up a clean Rust build, and I wanted to avoid
> the llvm build.
>
> For some reason, the apt-get install from the
blog.servo.org is up!
Feel free to put whatever you want there (and improve the theme). I plan to
put "This week in Servo"s up there, other posts or improvements to the
existing TWiS would be appreciated :)
-Manish Goregaokar
___
dev-ser
Fixed, thanks :)
-Manish Goregaokar
On Tue, Sep 2, 2014 at 4:14 AM, Steve Klabnik
wrote:
> I tweeted this, and got two questions:
> https://twitter.com/badboy_/status/506572974187896832
>
___
dev-servo mailing list
dev-servo@lists.mozilla.
Github aren't enough, feel free to ping someone in
IRC. Another thing you can do is trawl through web platform test failures
(some instructions here
<https://github.com/servo/servo/blob/master/src/test/wpt/README.md>). There
are a lot of failures due to trivial issues there.
-Manish
> Potential issues I see with the design:
>
> - there are Root, Handle and MutableHandle types that work on SM GC
> things, but there's no equivalent of the rooting analysis (that I could
> see) that prevents you from keeping unrooted GC thing pointers live over an
> operation that could GC.
>
>
https://github.com/servo/servo/wiki/Meeting-2014-10-27
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
related stuff without too many issues
(aside from the random compositor panics and lack of pdf support)
Highly suggest you try it!
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
What sort of static analysis pass is needed? Is it something our plugins crate
can do?
Also, my Reflector/InheritancePass PR provides match_unwrap_ty(), so linting
for Vec> is potentially a one line change (+boilerplate).
-Original Message-
From: "Josh Matthews"
Sent: 12/9/2014
https://github.com/servo/servo/wiki/Meeting-2014-12-08
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
This isn't really the domain of a browser *engine* IMO, it's the domain of
the browser as a whole (which we aren't, not right now anyway)
-Manish Goregaokar
On Tue, Jan 20, 2015 at 6:17 PM, Marc Collin wrote:
> How about a browser that, for once, empowers their users?
> Pe
Perhaps if we had some sort of priority system to the queue, where high
priority events (navigation, etc) override the other ones?
-Manish Goregaokar
On Thu, Jan 29, 2015 at 2:00 AM, Boris Zbarsky wrote:
> On 1/28/15 12:33 PM, Josh Matthews wrote:
>
>> I'm not certain what y
think of is html5ever, and it
already tracks nightlies.
Thoughts?
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
Alright, I'll start soon.
This makes travisifying easier too :)
-Original Message-
From: "Jack Moffitt"
Sent: 1/31/2015 9:01 PM
To: "Lars Bergstrom"
Cc: "Manish Goregaokar" ; "dev-servo"
Subject: Re: [dev-servo] Moving deps to nightlie
to help
avoid break the web, at the same time providing much better security
guarantees that (eventually) webapp devs don't have to worry about. Though
this is for the standards people to decide.
-Manish Goregaokar
On Wed, Feb 4, 2015 at 7:05 PM, Jack Moffitt wrote:
> > However, do s
instead of per-PR. This
way we don't double our build times or need extra buildslaves.
-Manish Goregaokar
On Tue, Feb 24, 2015 at 7:42 PM, Lars Bergstrom
wrote:
> Two questions about build flavors.
>
> 1) Should we change the default build type back from debug to release?
>
> Whe
follow any clear pattern.
I was more concerned about buildslaves running out and then the build
taking as long as T(debug)+T(release); instead of being just max(T(debug),
T(release))
-Manish Goregaokar
On Tue, Feb 24, 2015 at 9:56 PM, Jack Moffitt wrote:
> I'm +1 to make ./mach build do re
I added a set of builders (not hooked up with bors) to saltfs:
https://github.com/servo/saltfs/pull/15
If we merge that, we should be able to time it.
-Manish Goregaokar
On Tue, Feb 24, 2015 at 10:00 PM, Manish Goregaokar
wrote:
> With wpt? I think they're mostly the same, since
- Debug - 28:00 <http://build.servo.org/builders/linux2/builds/849>,
18:56 without WPT
- Release - 26:45, without WPT
<http://build.servo.org/builders/linux2-rel/builds/0>
We'll need to fix wpt on release
<https://github.com/servo/servo/issues/5056> to get proper nu
27;s go for it!
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
and friends, you can override this behavior:
- Copy servobuild.example to .servobuild
- Edit `cache-dir` and `cargo-home-dir` to point to wherever you want it
to be (`./.servo` and `~/.cargo` respectively if you want to keep the old
behavior).
Thanks,
-Manish Goregaokar
(It just landed, so be careful when pulling the latest master)
-Manish Goregaokar
On Sat, Mar 7, 2015 at 7:31 PM, Manish Goregaokar
wrote:
> Once https://github.com/servo/servo/pull/5168 lands the default .cargo
> directory for all dependency clones will be moved to the repo root, simila
2f6-4fdafbb5223b.png>
.
Thanks,
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
ependency)
which you think belongs in TWiS, don't hesitate add it to the notable
changes section in the draft! (nothing wrong about adding your own
changes). If we incrementally write it through the week, it becomes simple
to finish it up after the meeting and publis
odules whilst doing so.
Try to rebase and push all of your open PRs to master, too, github chokes
on these otherwise. You may need to do similar gymnastics whilst rebasing,
*or* just simulate a rebase via cherry picks (checkouts take a while if
you're crossing jgraham's PR)
Thanks,
-M
he bot behind the invocation is likely to change to @homu: or @bors:, but
for now we don't have the support in homu's codebase.
Bors is dead, long live homu!
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
being
tracked on Bugzilla and we' probably should continue with that); but for
now I don't see much of a reason to migrate, aside from avoiding having to
migrate
a larger Servo in the future.
-Manish Goregaokar
On Tue, Apr 28, 2015 at 10:33 AM, Robert O'Callahan
wrote:
> On Tu
worse
option IMO.
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
Appveyor provides free CI for Windows, and is pretty easy to set up.
Since we already have Travis set up on almost all deps, should we do the same
with Appveyor? I tried it out on rust-url[1] and it worked pretty smoothly (yml
copied from Glutin)
Most of our deps should just work with Windows,
ther image libs
-Manish Goregaokar
On Sun, May 10, 2015 at 3:03 PM, Sean McArthur
wrote:
> It can be a sanity check that a library builds on Windows. Mostly that all
> its dependencies don't suddenly lose support or stop compiling.
>
> That's the only reason I'm consi
are enough env vars
available to check for branches and PRs). This would be fiddly, but it
should work. It would be nice to set up a shell script on servo-s3 and curl
it from all travis files (making this process easy to update)
-Manish Goregaokar
On Fri, May 22, 2015 at 7:19 PM,
This sounds good. We can expand as needed.
-Manish Goregaokar
On Tue, May 26, 2015 at 9:09 PM, Jack Moffitt wrote:
> > Who should that be? Everyone on
> https://github.com/orgs/servo/teams/owners ?
> > Everyone on https://github.com/orgs/servo/people ? Some other set of
&
The comment goes away in that PR :)
As for Arc, I think the plan is to divide by the refcount; to get a
"weight" sort of thing.
Note that we only need to worry about shared references, not all non-owning
references (borrows can be ignored)
-Manish Goregaokar
On Mon, Jun 1, 2015
... it sets things on fire.
I think Rust has a slightly different setup for try which somehow works,
but in our case @bors-servo: try on jgraham's PR
<https://github.com/servo/servo/pull/6244>queued nearly 200 PRs for trying.
-Manish
ittents let jgraham know (and disable them).
We can un-gate if there are too many of them.
Thanks,
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
As far as tryserver goes it should be easy to patch homu to accept a wider
list of "try-enabled" users, which we can hand out liberally like Firefox
does.
First we should get around to fixing the try feature though :)
-Manish Goregaokar
On Tue, Jun 2, 2015 at 11:29 PM, James Gra
is just
one bikeshed away.
ccing part of the rust libs team in case they're interested in these
results.
Thanks,
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
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 wrote:
> Hi,
>
> I often like to work on
the versions in toml files though.
-Manish Goregaokar
On Tue, Jun 16, 2015 at 2:22 AM, Simon Sapin wrote:
> Some of our dependencies to crates on crates.io are declared in
> Cargo.toml files like this:
>
> [dependencies]
> foo = "*"
>
> To be honest, I’m not su
Yes, I was talking about Crates crates too :)
My plan is to upgrade Rust often now that it's pretty stable, which
automatically keeps our libraries
up to date too. But if we don't want to do that I guess pinning to semver
is okay.
-Manish Goregaokar
On Tue, Jun 16, 2015 at 2:52 AM, S
less linear history is okay, especially when
most of the PRs being rolled up are minor ones.
Thanks,
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
s. If something breaks, we can bisect if necessary.
-Manish Goregaokar
On Fri, Aug 7, 2015 at 3:10 PM, Ms2ger 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 m
That sounds doable. I'm open to helping maintain aster's nightlyness.
-Manish Goregaokar
On Thu, Aug 20, 2015 at 9:47 PM, Simon Sapin wrote:
> On 20/08/15 17:50, Ms2ger wrote:
>
>> Hi all,
>>
>> Recently, homu has regularly rejected PRs to rust-layers be
work. `git log --topo-order` iirc does
bunching of commits by parent chains (verses `git log --date-order`, which
I *think* is the default).
-Manish Goregaokar
On Thu, Oct 15, 2015 at 7:17 PM, Anthony Ramine wrote:
> Le 15 oct. 2015 à 14:42, Lars Bergstrom a écrit :
>
> > - Aut
Barosl just verified in chat that it makes an empty commit with the merge
information even when rebasing.
I'm now pretty ambivalent towards this. I don't mind linear histories, but
... I can handle graphy ones too.
-Manish Goregaokar
On Fri, Oct 16, 2015 at 2:08 AM, Manish Goregao
s://github.com/brson/multirust> is a way of
maintaining multiple Rust installs in parallel, if you don't want to
uninstall your nightly.
I'll let you know when stuff is working again.
-Manish Goregaokar
___
dev-servo mailing list
dev-se
I'll get around to updating all of the deps to work with it later.
@Divya try a fresh checkout of rust-layers. I tweaked the crates so that
they don't need plugin support when being built standalone (since the
plugins are only needed for Servo integration to work)
-Manish Goregaokar
O
Delete your Cargo.lock
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
CI (there was an incident when
this stopped working, IIRC). It's not an "actual" web platform test.
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
mach cargo, ./mach rustc) instead.
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
just have to do it.
-Manish Goregaokar
On Thu, Oct 22, 2015 at 4:03 AM, Divya Jain wrote:
> Hi Manish,
>
> So with you advice, I reset the HEAD to the commit you mentioned in the
> previous mail. The cargo override for Servo is building fine with the
> commit mentioned in the em
CONTRIBUTING sgtm
-Manish Goregaokar
On Thu, Oct 22, 2015 at 4:51 PM, Paul Rouget wrote:
> Maybe I could merge it into CONTRIBUTING.md? Or README.md?
> What would you recommend?
>
> On Thu, Oct 22, 2015 at 12:54 PM, Josh Matthews
> wrote:
> > I'd like to move it into
et to implement, fine, if not, then re-check your implementation
of overrideMimeType().
(You can open a pull request first if you wish)
Thanks,
-Manish Goregaokar
On Sun, Oct 25, 2015 at 2:33 AM, Jitendra Jain wrote:
> Hello,
>
> We are working on M1504: Implement support for missing XMLH
You need to add a link to the spec where you got the webidl from. The other
interfaces all have a link to html.spec.whatwg.org or similar.
-Manish Goregaokar
On Sun, Nov 1, 2015 at 11:02 AM, JIGAR SHARDA
wrote:
> Hi All,
>
> I am trying to add a new interface and while running the ./
e can implement the spec as is (which require major changes and
affect perf or complexity), or we can hope that nobody relies on this
behaviour (given that it's not followed by major browsers) and implement it
as logically as possible, keeping in line with other browsers (and leaving
a bug open
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-P
That sounds like a good idea. Perhaps we should do this on the
mozilla-central side; move things out of mochitest into WPT?
Is there an easy way of identifying browser-agnostic mochitests?
-Manish Goregaokar
___
dev-servo mailing list
dev-servo
We probably can't do it in an automated way; tests being converted to WPT
need to match spec and usually also need a spec link in the top.
We could, however, import them wholesale into Servo's
tests/wpt/mozilla/foo, and then manually pick through them.
-Manish Goregaokar
On Wed, Nov
le changes that require internal-only APIs to trigger.
>
Agreed, still need webdriver.
Once we get webdriver it might be nice to translate&upstream even more
content mochitests to WPT or wherever we'll be keeping the webdriver tests.
-Manish Goregaokar
___
g
it) and filing a bug -- if it's not too hard to do so -- is what we should
do.
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
Oh, yeah, in that case we should just mimic the other browsers and file
bugs.
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
can see it in action here <https://github.com/servo/saltfs/pull/160>.
Thanks,
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
Bit late to the party, but I think there are a couple of core issues
causing this debate:
There are actually two kinds of trust involved. First is the trust to not
botnet the CI, basically
everyone here (at least everyone with try) has that. But that's not the
actual one being discussed
here. The
, you'll also need to add the webidl file (as well as a
dom module) for ImageData
<https://html.spec.whatwg.org/multipage/scripting.html#imagedata>.
Do you have a link to the spec for ImageRequest? I couldn't find it after
some quick searching.
Let
since Magic DOM
probably will change the landscape.
-Manish Goregaokar
On Sat, Dec 12, 2015 at 11:41 PM, Anthony Ramine wrote:
> > Le 12 déc. 2015 à 09:56, Lars Bergstrom a écrit :
> >
> > Thanks to everybody for a fantastic workweek! I was impressed by how
> > well w
We were thinking of SQLite4, however there seem to be people
<https://twitter.com/floydophone/status/676540491068891137> using
rocksdb+rust in production (https://github.com/spacejam/rust-rocksdb?)
-Manish Goregaokar
On Tue, Dec 15, 2015 at 8:57 AM, Jack Moffitt wrote:
> Probably th
Apparently SQlite4 has a good kv store included, but nox knows it better
and understands the justification.
I think firefox uses sqlite (3?); it uses sqlite for everything.
-Manish Goregaokar
On Tue, Dec 15, 2015 at 9:12 AM, Jack Moffitt wrote:
> Why would we use a nearly full sql eng
g necessary things too, not only
focusing on new experiments :)
Thanks,
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
More or less. If you're going to pick leveldb it would be better to use
rocksdb (which is a leveldb fork, IIRC) since there is a Rust wrapper
that's in use by others.
-Manish Goregaokar
On Tue, Dec 15, 2015 at 11:03 AM, Shing Lyu wrote:
> Thank you guys.
>
> So from what I
ype PR messages since nobody wants to
retype what the issue says.
-Manish Goregaokar
On Sun, Feb 21, 2016 at 5:58 AM, Lars Bergstrom
wrote:
> 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
This has been deployed.
https://github.com/servo/servo/pull/9884#issuecomment-192805671
The builder is called "status-appveyor" and behaves similar to Travis.
I'll be watching the queue today and tomorrow. Revert the salt deployment if
anything goes wrong.
Thanks,
-Manish
larsb...@mozilla.co
It's a key milestone for stability on windows. We don't release nightlies
for any desktop platform yet.
Thanks,
-Manish Goregaokar
On Sun, Mar 6, 2016 at 8:23 AM, Phil Sweeney wrote:
> Great works.. is this a key milestone for the eventual delivery of Windows
> nightly bu
-Manish Goregaokar
On Wed, Mar 16, 2016 at 1:37 AM, Manish Goregaokar
wrote:
>
> On Tue, Mar 15, 2016 at 3:13 PM, Zhen Zhang wrote:
>
>>
>> 1. About FileList API, It is said to be *at risk* to be replaced by
>> Array. <https://w3c.github.io/FileAPI/#filelist-secti
Last time I tried it, Servo with LLVMpipe and WR wasn't too bad, even on
the moire demo. It was slightly worse than Servo without WR, which IIRC has
similar performance as Gecko.
-Manish Goregaokar
On Tue, Mar 29, 2016 at 2:20 AM, Bobby Holley wrote:
> In general, does the software-
etings aren't
happening anyway.
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
s some use of
rev-list and skip. But it's possible; I recall doing this once.
Thanks,
-Manish Goregaokar
On Tue, Apr 26, 2016 at 11:50 PM, Gregory Szorc wrote:
> Servo developers,
>
> I noticed that Servo and a number of other Servo related Git repos have
> tons of merge commi
Yeah, it does, that's what homu does currently.
-Manish Goregaokar
On Wed, Apr 27, 2016 at 9:08 PM, Nick Fitzgerald
wrote:
> On Wed, Apr 27, 2016 at 8:34 AM, Matt Brubeck
> wrote:
>
> > On Wed, Apr 27, 2016 at 7:25 AM, Manish Goregaokar <
> manishsm...@gmail.com>
it
> doesn't. If there is a bad merge commit, `git bisect` will clearly point
> to it as the culprit; while problems introduced in a rebase will in no
> way indicate the rebase as the cause.
>
note that git bisect gets rather muddled with merge commits unless you
teach it to on
ntry.
It might also be nice to have bors' approval message note travis failures
(only travis for now, appveyor isn't always passing) if a travis-failing PR
is approved.
-Manish Goregaokar
On Fri, May 6, 2016 at 8:43 PM, Josh Matthews wrote:
> Github introduced templates for issue
This is the folder you want:
https://static.rust-lang.org/dist/2016-05-14/index.html
-Manish Goregaokar
On Mon, May 16, 2016 at 3:17 PM, wrote:
> Hi,
>
> I am trying to port Servo to Power8/LE platform (ref thread:
> https://groups.google.com/forum/#!topic/mozilla.dev.servo
endency paths do not
have it enabled). If this turns out to be working reliably I'd prefer to do
this, though it may unexpectedly break in the future.
-Manish Goregaokar
On Tue, May 31, 2016 at 8:04 PM, Jack Moffitt wrote:
> > Doing it via Cargo features sounds like the better
Oh, interesting. I have had strange errors when not fully specifying the
features but the reason might have been something else.
We should just do that, then, agreed.
-Manish Goregaokar
On Tue, May 31, 2016 at 8:21 PM, Simon Sapin wrote:
> On 31/05/16 16:40, Manish Goregaokar wrote:
>
It should be net/device/bluetooth. For some reason the crate is imported as
"device" instead of "devices" in net
-Manish Goregaokar
On Wed, Jun 1, 2016 at 1:29 PM, Dirkjan Ochtman wrote:
> On Tue, May 31, 2016 at 4:51 PM, Simon Sapin wrote:
> >> It is possi
It seems like it's still checking the git repo for the feature. Might be
worth landing your devices changes and proceeding from there.
-Manish Goregaokar
On Thu, Jun 2, 2016 at 12:56 PM, Dirkjan Ochtman wrote:
> On Wed, Jun 1, 2016 at 10:53 AM, Manish Goregaokar
> wrote:
> >
oo, mostly script and
then layout -- so it might be best to not split style out.
Thanks,
-Manish Goregaokar
On Mon, Jun 20, 2016 at 8:31 PM, Lars Bergstrom
wrote:
> As many of you may have seen from the document
> (
> https://docs.google.com/document/d/1uubYE7JXaVY10PoAY9BVx8A-T11Zx
anges
will trigger a m-c CI build in Servo. Do lockfile changes cause this build?
What about edits to util?
Thanks,
-Manish Goregaokar
On Tue, Jun 21, 2016 at 4:16 PM, Manish Goregaokar
wrote:
> My main issue is that backouts aren't addressed. They are reasonably
> common in m-c (admitt
become less of a pain, while actual changes affecting both will still
be tested. The reverse can also exist, as a checkbox in the trychooser
interface.
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
icts.
> You make it sound like refactorings don't introduce bugs. ;)
>
Sure they can, but they should be less likely to :)
We will still have the full CI run on a sync so these will get caught, just
not immediately.
-Manish Goregaokar
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
Coordinating rollups across two repos will be a pain. The proposed
automation sounds better to me.
-Manish Goregaokar
On Thu, Jun 23, 2016 at 10:08 AM, Michael Howell wrote:
> If the model you're proposing is "almost isomorphic" to roll ups, then why
> not just use roll up
We rarely use ranges, just a minimum version, and aside from major version
differences cargo just picks the max.
dev-servo@lists.mozilla.org wrote:
> Is there a risk that non-overlapping version ranges in dependent Cargo.toml
> files will cause multiple versions of the package to be imported? Or
resumably we want to crawl
>> the Cargo.toml files in that case? And again, will it be obvious that needs
>> to happen from the Cargo.lock diff?
>>
>> On Thu, Jun 23, 2016 at 9:32 AM, Manish Goregaokar
>> wrote:
>>> We rarely use ranges, just a minimum version,
1 - 100 of 174 matches
Mail list logo
