Re: [dev-servo] Should we use Dependabot?

To me, the very act of having to acknowledge more email notifications is being incurred extra work. > Le 4 mai 2020 à 18:53, Josh Matthews a écrit : > > In my experience, Taskcluster returns results within 30 minutes of the PR > opening, so all I need to do is check the in-PR results for a

Re: [dev-servo] Should we use Dependabot?

Hello, > * should we use Dependabot at all? Personally I don't like it. We most often know when we should be updating stuff, and making semver-compatible bumps for the sake of making them doesn't seem very important to me. > * is our policy to ban duplicate versions by default still useful?

Re: [dev-servo] Merging mozjs and rust-mozjs

I'm ok with that, especially given that's what I intend to do with my independent looking into how we could improve the SM vendoring situation (except that the top-level crate in my case is an unpublishable tool for handling the rest of the repo). > Le 11 janv. 2020 à 00:35, Josh Matthews a

Re: [dev-servo] Last week for testing potential IRC replacements

Why isn't Freenode a candidate for the switch? The Daala team hangs there so it's not like there is no precedent. > Le 3 oct. 2019 à 18:28, Josh Bowman-Matthews a écrit : > > If anybody is having trouble accessing the document, here's the relevant > information: > > Our Matrix/Riot.IM

Re: [dev-servo] Tidy lints

We don't make use of rustfmt yet though (right? I was under a rock for 2 weeks so if I missed this excellent improvement, ignore me), so let's do that first IMO. > Le 19 août 2018 à 19:43, Bobby Holley a écrit : > > rustfmt fits the bill, so I think it makes sense to retire > that particular

Re: [dev-servo] Tidy lints

I don't know, but if your question is "would you mind using a tool to automate that stuff instead of a lint that complains?" then my answer is "yes, I too don't enjoy reordering things by hand". > Le 19 août 2018 à 13:58, Emilio Cobos Álvarez a écrit : > > Can we enable import reordering in

Re: [dev-servo] Tidy lints

I personally think they are extremely useful, because if they don't exist I end up fixing order of things when I touch code around them. It's almost obsessive. That being said, it's 2018 and rustfix should be doing it for us. > Le 18 août 2018 à 18:28, Emilio Cobos Álvarez a écrit : > > Do

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

to be extra clear). I wouldn't mind a tidy thing choking on the slightest appearance of "{:?}" in those files. > Le 13 janv. 2018 à 15:36, Anthony Ramine <n.ox...@gmail.com> a écrit : > > In the PR you link, AFAICT you also removed some uses that were just very >

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

I would much rather prefer if we just checked that we didn't use the Debug impls of large types. We could also just not derive them in release mode. In the PR you link, AFAICT you also removed some uses that were just very small enums or even integers, which may not be necessary. > Le 13 janv.

Re: [dev-servo] Should commits landed in servo individually pass all tests?

Let me add some necessary additions to this quite rude email... I am sorry, Manish. > Le 3 nov. 2017 à 10:33, Anthony Ramine <n.ox...@gmail.com> a écrit : > > >> Le 3 nov. 2017 à 01:00, Manish Goregaokar <manishsm...@gmail.com> a écrit : >> >>

Re: [dev-servo] Should commits landed in servo individually pass all tests?

> Le 3 nov. 2017 à 02:10, Gregory Szorc a écrit : > > On Thu, Nov 2, 2017 at 5:00 PM, Manish Goregaokar > wrote: > >> > > The Firefox repo has the same dilemma. Ideally history is good down to the > commit level. In reality, we only test on "push

Re: [dev-servo] Should commits landed in servo individually pass all tests?

> Le 3 nov. 2017 à 01:00, Manish Goregaokar a écrit : > > So I and emilio were discussing whether or not to squash > https://github.com/servo/servo/pull/18750 and it seemed like we have > different ideas of how "atomic" commits should be before landing. It should

Re: [dev-servo] Let's merge core-foundation-rs, core-text-rs, and core-graphics-rs

I vote macarena. > Le 25 oct. 2017 à 21:23, Jack Moffitt a écrit : > > What do you propose as the new crate name? ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Memory reporting in Servo: the next step

> Le 6 oct. 2017 à 07:58, Nicholas Nethercote a écrit : > > Not being able to use derive doesn't worry me, because it's just a > convenience. I just looked through all the external crates that implement > HeapSizeOf and hardly any are using derive. Most don't use derive

Re: [dev-servo] Memory reporting in Servo: the next step

> Le 6 oct. 2017 à 03:27, Nicholas Nethercote a écrit : > > I see two options. > > - Overwrite the heapsize crate on crates.io with the malloc_size_of code. So > the crate name wouldn't change, but the API would change significantly, > and > it would still be on

Re: [dev-servo] custom derive for Deref/DerefMut

> Le 14 juil. 2017 à 02:13, Bobby Holley a écrit : > > There's a lot of boilerplate involved just to make a newtype [1]. Is this > something we could add a custom derive for? We don't use that many newtypes to justify writing a custom derive for that IMO. Often we don't

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

"Backed out changeset 90036d4d378e (bug 17564) because gecko-side patch caused bustage on Windows. r=backout on a CLOSED TREE" I see issues in that: - Mentioning a Mercurial changeset hash when just a PR number is enough - Putting the reason of the backout directly in the title instead of the

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

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

Re: [dev-servo] Consider using GitCop

> Le 2 juin 2017 à 18:22, Boris Zbarsky <bzbar...@mit.edu> a écrit : > > On 6/2/17 11:50 AM, Anthony Ramine wrote: >>> Though not required, it’s a good idea to begin the commit message with a >>> single short (less than 50 character) > > Just so we're cl

Re: [dev-servo] Consider using GitCop

> Le 2 juin 2017 à 17:00, Boris Zbarsky <bzbar...@mit.edu> a écrit : > > On 6/2/17 5:18 AM, Anthony Ramine wrote: >> In the following screenshot, you can see one doesn't even know what that >> commit is supposed to do from its title, because it is way too long to

[dev-servo] Consider using GitCop

Friendly ping to mailing list about https://github.com/servo/servo/issues/16138, which I remembered because of https://github.com/servo/servo/pull/17138#issuecomment-305733987 In the following screenshot, you can see one doesn't even know what that commit is supposed to do from its title,

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

KILL IT > Le 16 mars 2017 à 15:30, Lars Bergstrom a écrit : > > Opinions? ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Please avoid @-mentioning people in commit or PR messages

> Le 1 mars 2017 à 15:41, Kartikaya Gupta a écrit : > > What was the rationale behind this, out of curiousity? Note that this is GH's default behaviour too when hitting the big green button. ___ dev-servo mailing list

Re: [dev-servo] PSA: Breaking updates to geckolib dependencies will break mozilla-central

I'm not sure what you mean. Do you mean for example that my serde 0.8 to serde 0.9 bump will break m-c? > Le 17 févr. 2017 à 23:08, Bobby Holley a écrit : > > Now that we have the VCS sync system running, changes to servo/servo are > immediately mirrored over to

Re: [dev-servo] Quantum CSS (stylo) builds now on m-c

I have a few questions: Which changes will need to go through Firefox CI? How long does Firefox CI take to run all the tests? What happens if the bug is on Firefox's side? > Le 13 févr. 2017 à 20:50, Bobby Holley a écrit : >

Re: [dev-servo] Finding contributors who might be interested in a particular issue

Or just use git-shortlog. :) git shortlog --no-merges -nse --since="2 weeks ago" > Le 6 janv. 2017 à 17:04, Josh Matthews a écrit : > > Hi folks! I occasionally file issues that could be thought of as "good third > or fourth issues", where it's not clear that marking

[dev-servo] PSA: Don't publish crates with the nightly from the last few days

I managed to the whole Servo CI by trying to fix the already busted expat-sys package. This didn't go well because of https://github.com/rust-lang/cargo/issues/2326 Should be fixed now with expat-sys 2.1.2, which I packaged using the stable channel.

Re: [dev-servo] IndexDB project

> Le 15 déc. 2015 à 04:44, Manish Goregaokar a écrit : > > 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. In SQLite 4 hides itself a K/V

Re: [dev-servo] Mozlando meeting notes

> Le 12 déc. 2015 à 09:56, Lars Bergstrom a écrit : > > Thanks to everybody for a fantastic workweek! I was impressed by how > well we did having a lot of hard conversations about long-pending > architectural changes, drilling into the open issues, and determining > the

[dev-servo] PSA: The Cast structures and related traits are no longer

Hello, #8041 [1] just landed, and that means you no longer have to import NodeCast and friends from InheritTypes. Here are a few code snippets that describe the changes: NodeCast::from_ref(node) node.upcast::() NodeCast::from_layout_js(node) node.upcast::()

[dev-servo] Always Be Closing

Hello, There are currently more than 60 PRs opened, and the oldest one's ID is 3,000 lower than the newest. This is starting to get out of hand. I suggest we should be Always Be Closing stale pull requests instead of letting them linger. We could have a wiki page or something of interesting

Re: [dev-servo] Always Be Closing

at appear to be abandoned > and are still desirable, so we could link to > https://github.com/servo/servo/pulls?q=is%3Apr+is%3Aclosed+label%3AS-needs-new-owner > for a list of closed PRs with that label applied, I guess. > > Cheers, > Josh > > On 2015-09-13 9:00 A

Re: [dev-servo] Always Be Closing

I see. I've also noticed that pushing new code doesn't remove S-needs-rebase if the code can now merge. Is that intended too? Le 14 sept. 2015 à 02:12, Josh Matthews a écrit : > No; S-needs-rebase is applied automatically to PRs when homu posts a Merge > Conflict

Re: [dev-servo] Always Be Closing

S-needs-rebase and S-awaiting-review should be mutually exclusive though, right? Le 14 sept. 2015 à 01:49, Josh Matthews a écrit : > I will point out that any PR with S-awaiting-review should not be closed; > that means that the failure is on our end since new code has

Re: [dev-servo] Reviewers

Le 1 sept. 2015 à 05:49, Simon Sapin a écrit : > On 01/09/15 02:21, Josh Matthews wrote: >> https://github.com/servo/servo/wiki/Meeting-2015-08-31 > >> Submodule reviews >> >> html5ever reviews > > I have delayed these html5ever reviews for various reasons, but they’re

Re: [dev-servo] Representing mutation of children lists

Le 23 juil. 2015 à 23:50, Anthony Ramine n.ox...@gmail.com a écrit : snip/ [1] https://github.com/servo/servo/pull/6660 For those interested, here is how I plan to use the children_changed() virtual method: https://github.com/nox/servo/commit

[dev-servo] Representing mutation of children lists

Hello, I'm currently trying to optimise Node.childList and to do so I need to propagate changes in children of nodes to the corresponding NodeList. I took upon the task of cleaning the mess that are the various virtual methods called on insertion and removal of nodes and introduced a new