There was supposed to be a a discussion about whether the charter 1)
excluded EME, 2) included EME, or 3) included EME with protection for
security researchers. I didn't see much discussion, then the charter was
simply changed to option 2.
https://github.com/w3c/charter-media-wg/issues/2
I think w
On Tuesday 2019-04-09 13:55 +0300, Henri Sivonen wrote:
> On Mon, Apr 8, 2019 at 11:32 PM L. David Baron wrote:
> >
> > The W3C is proposing revised charters for:
> >
> > Internationalization (i18n) Working Group
> > https://www.w3.org/2019/04/proposed-i18n-wg-charter.html
> > https://lists.
(Mozilla fan boy here, not an employee)
Just to chime in that a number of us involved in the last great W3C EME/DRM
fight are going to chime in that we'd like to see protections for security
researchers that do privacy and security work on browsers, specs, etc. The
idea that didn't go very far las
Yeah, I did consider "non-e10s" for awhile and maybe it is the better
choice. But here are my counter arguments:
1) One of the goals of this change is to de-clutter the treeherder UI.
Using an 8 character symbol suffix runs counter to that goal (even if it is
still less cluttered overall).
2) Peop
Le 09/04/2019 à 21:26, Andrew Halberstadt a écrit :
Hi everyone,
Almost all of our tasks in CI now run with e10s enabled, we only run
non-e10s
with Fennec and Linux32. Yet the "default" state in terms of our CI, is
still non-
e10s. You can see this by the presence of "-e10s" suffixes in task la
Hi everyone,
Almost all of our tasks in CI now run with e10s enabled, we only run
non-e10s
with Fennec and Linux32. Yet the "default" state in terms of our CI, is
still non-
e10s. You can see this by the presence of "-e10s" suffixes in task labels
and
treeherder symbols.
To better reflect reality
If you use `hg rebase` or `hg pick`, you should disable the format-source
extension until this is resolved:
(data loss) Suspected bad interaction between hg rebase and format-source
https://bugzilla.mozilla.org/show_bug.cgi?id=1542871
You can disable this extension by commenting out a line in you
On 4/9/19 10:37 AM, Brian Grinstead wrote:
I'll think some more about if there’s a way to limit the risk of losing test
coverage.
One simple thing is to restrict the change to
> We could similarly remove type="text/css" from
-- Original Message --
From: "Gian-Carlo Pascutto"
To: dev-platform@lists.mozilla.org
Sent: 2019-04-09 11:00:14 AM
Subject: Re: Intent to deprecate - linux32 tests starting with Firefox
69
On 5/04/19 15:35, jma...@mozilla.com wrote:
Currently linux32 makes up about .77% of our tot
> On Apr 8, 2019, at 8:55 PM, Cameron McCormack wrote:
>
> On Tue, Apr 9, 2019, at 1:39 PM, Brian Grinstead wrote:
>> I'd like to rewrite markup in the tree to avoid using the [type]
>> attribute on
On 5/04/19 15:35, jma...@mozilla.com wrote:
> Currently linux32 makes up about .77% of our total users. This is
> still 1M+ users on any given week.
I asked jmaher what percentage of our Linux users this is. It's 21%.
This doesn't seem small.
On top of that, we know that not all distros have tel
Thank you. I will update the script(s) to use that list.
> On Apr 9, 2019, at 7:52 AM, Kartikaya Gupta wrote:
>
> On Mon, Apr 8, 2019 at 11:39 PM Brian Grinstead
> wrote:
>> I've prepared a script that rewrites this across the tree. The script and
>> the generated patch can be seen at
>> htt
On Tue, Apr 9, 2019 at 12:01 AM Felipe G wrote:
>
> > I'm writing to the list in order to:
> > 2) See if there are any general best-practices for getting this type of
> > change reviewed / landed. For example, should we prefer separate commits /
> > reviews per directory, or does a single tree-wid
On Mon, Apr 8, 2019 at 11:39 PM Brian Grinstead wrote:
> I've prepared a script that rewrites this across the tree. The script and the
> generated patch can be seen at
> https://bugzilla.mozilla.org/show_bug.cgi?id=1542877. The following
> directories are excluded:
>
> - third_party
Just as a
On 09/04/2019 15:37, Brian Grinstead wrote:
I'll think some more about if there’s a way to limit the risk of losing test
coverage. Perhaps doing it in a couple of separate patches would result in a
final patch that’s more manageable to review: first do simpletest.js and other
common helper scr
> On Apr 9, 2019, at 2:31 AM, Anne van Kesteren wrote:
>
> On Tue, Apr 9, 2019 at 5:56 AM Cameron McCormack wrote:
>> On Tue, Apr 9, 2019, at 1:39 PM, Brian Grinstead wrote:
>>> I'd like to rewrite markup in the tree to avoid using the [type]
>>> attribute on
The reasoning is:
- If we don't rewrite existing test files then it will keep getting propagated
in new tests as old ones get cloned.
- It's a small cleanup that makes existing tests slightly easier to read
(especially when combined with other boilerplate reduction).
- I was under the impression
On Tue, Apr 9, 2019 at 12:42 PM Henri Sivonen wrote:
> On Mon, Apr 8, 2019 at 11:11 PM L. David Baron wrote:
> >
> > The W3C is proposing a new charter for:
> >
> > Web & Networks Interest Group
> > https://www.w3.org/2019/03/web-networks-charter-draft.html
> > https://lists.w3.org/Archive
On 09/04/2019 11:16, James Graham wrote:
I also wonder if there are other non-wpt tests that would be broken by
such a change??
This was my thought as well. Is there a compelling reason to want to do
this rewrite for extant HTML mochitest test files?
~ Gijs
_
On Mon, Apr 8, 2019 at 11:32 PM L. David Baron wrote:
>
> The W3C is proposing revised charters for:
>
> Internationalization (i18n) Working Group
> https://www.w3.org/2019/04/proposed-i18n-wg-charter.html
> https://lists.w3.org/Archives/Public/public-new-work/2019Apr/0004.html
> diff from
On Mon, Apr 8, 2019 at 11:11 PM L. David Baron wrote:
>
> The W3C is proposing a new charter for:
>
> Web & Networks Interest Group
> https://www.w3.org/2019/03/web-networks-charter-draft.html
> https://lists.w3.org/Archives/Public/public-new-work/2019Mar/0010.html
>
> Mozilla has the opport
As of bug 1541792, it is not possible to define XPCOM components with
NSMODULE_DEFN anymore. This follows the recent changes announced by Kris
Maglione in
https://lists.mozilla.org/pipermail/dev-platform/2019-February/023503.html
After those changes, there were too few remaining components not usi
On 09/04/2019 10:31, Anne van Kesteren wrote:
On Tue, Apr 9, 2019 at 5:56 AM Cameron McCormack wrote:
On Tue, Apr 9, 2019, at 1:39 PM, Brian Grinstead wrote:
I'd like to rewrite markup in the tree to avoid using the [type]
attribute on
On Tue, Apr 9, 2019 at 5:56 AM Cameron McCormack wrote:
> On Tue, Apr 9, 2019, at 1:39 PM, Brian Grinstead wrote:
> > I'd like to rewrite markup in the tree to avoid using the [type]
> > attribute on
The corruption can manifest itself in different forms. The most obvious
one is when you get an error while pulling. The less obvious one is when
some file looks weird when you look at it.
The specifics of the corruption is that it involves files that were
renamed/moved/copied and marked as such in
26 matches
Mail list logo
