Re: To what extent is sccache's distributed compilation usable?

[Marcos Caceres]

On Friday, October 25, 2019 at 4:14:05 AM UTC+11, Jeff Gilbert wrote:
> My home Ryzen 3900x builds windows debug clobbers in under 10 minutes.

Whoa, that's awesome! 

> Beefy desktops are relatively cheap, and I believe we continue to encourage
> firefox-builders to request desktop workstations for builds.

Do you know if it's possible to cross compile on one of those for to target 
MacOS? I'd like to build on, and for, MacOS. 

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

Deprecating DTD for localization in Firefox UI

[Zibi Braniecki (Gandalf)]

Hi all,

tl;dr: Please use Fluent instead of adding or changing existing DTD strings.

== DTD and Fluent ==

DTD has been used as the core localization format and API inside of Firefox
since the dawn of Mozilla, allowing us to localize our XUL and other XML
files.

Unfortunately, DTD comes with a set of quite painful limitations, including
the so called Yellow Screen of Death which causes a crash at startup and
requires a complicated manual process by each user to recover. We’ve
recently been affected by this on beta [1].

For a couple years now, we’ve been working on a replacement for DTD - a new
localization system called Fluent [2] which (among other things) addresses
the shortcomings of DTD.

== Deprecating DTD for localization in browser chrome ==

Now that Fluent meets the performance requirements to replace DTD, we would
like to deprecate the DTD file format as a localization mechanism in
Firefox.

Please could you:

   1.

   Avoid introducing any new DTD strings in mozilla-central.
   2.

   If existing DTD strings would need to be changed, migrate them to Fluent
   [3] instead of updating the message identifier in DTD.


There are a few small areas where integrating Fluent is not entirely
trivial (most notably UA widgets) and those will be exempted from the
deprecation.

In case you believe there are technical reasons to continue using DTD in
your project, please consult fluent-reviewers group [4], which has been
recently extended with additions of Jared Wein, Gijs Kruitbosch and Edward
Lee. They can be reached in #fluent on Slack or fluent-reviewers on
phabricator.

The change does not affect release or beta uplifts, since we don’t change
strings in those. ESR uplifts will be exempted from the deprecation.

== Dashboard ==

In order to visualize our progress, we recently updated our dashboard:
https://arewefluentyet.com/

The new version introduces three milestones:

M1 - Removal of DTD from browser.xhtml - addresses Yellow Screen of Death
[5]

M2 - Migration of the startup path to Fluent [6]

Mx - Migration of the whole mozilla-central to Fluent [7]

Additional milestones may be added as we identify them.

Each one of these milestones will enable a set of new features for Firefox,
and deprecating DTD for localization is aiming to help us achieve them
sooner.


If you have any questions, let me know!

Cheers,

zb.

[1]
https://www.reddit.com/r/firefox/comments/d5wq0z/firefox_crashes_on_browser_startup_and_flashes/


[2] https://firefox-source-docs.mozilla.org/intl/l10n/l10n/index.html

[3]
https://firefox-source-docs.mozilla.org/intl/l10n/l10n/fluent_migrations.html

[4] fluent-reviewers group  (#fluent on Slack):

   -

   Francesco Lodolo
   -

   Jared Wein
   -

   Gijs Kruitbosch
   -

   Edward Lee
   -

   Axel Hecht
   -

   Staś Małolepszy
   -

   Zibi Braniecki

[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1579477

[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1501881

[7] https://bugzilla.mozilla.org/show_bug.cgi?id=1581212
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: To what extent is sccache's distributed compilation usable?

[Jeff Gilbert]

My home Ryzen 3900x builds windows debug clobbers in under 10 minutes.
Beefy desktops are relatively cheap, and I believe we continue to encourage
firefox-builders to request desktop workstations for builds.

On Wed, Oct 23, 2019 at 11:20 PM Marcos Caceres 
wrote:

> On Thursday, October 24, 2019 at 6:46:08 AM UTC+11, Christopher Manchester
> wrote:
> > As announced in this week's project call, sccache-dist schedulers have
> been
> > deployed to mozilla offices, and those with hardware available can enroll
> > servers based on the documentation here
> > <
> https://firefox-source-docs.mozilla.org/build/buildsystem/sccache-dist.html#steps-for-setting-up-a-server
> >.
>
> Just a reminder to not forget about us remotees! We are dying out here
> with 1+ hour compile times so anything would really help (even 20-20%
> improvement would go a long way). A lot of us have spare old macs, and if
> we can put them to good use with this, that would be amazing.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using MozPhab without Arcanist

[Dan Mosedale]

Also, if you did the double self-update to move over to pip while
running under pyenv, moz-phab may suddenly disappear from your path
until you restart your shell.

Dan

Am Do., 24. Okt. 2019 um 03:55 Uhr schrieb Axel Hecht :
>
> Am 24.10.19 um 12:13 schrieb Henrik Skupin:
> > glob wrote on 23.10.19 17:56:
> >
> >> It's available now - make sure you're running the latest version by
> >> running `moz-phab self-update`.
> >
> > That's what I did yesterday, but as it looks like the self-update
> > actually didn't update my version to the latest MozPhab-0.1.55. I will
> > check soon with this version. Thanks!
> >
> > Henrik
> >
>
> You need to run self-update twice to move over to the pip version.
>
> Also, make sure to not run it while in a virtualenv like I did.
> Otherwise you end up uninstalling and installing it from scratch ;-)
>
> Axel
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using MozPhab without Arcanist

[Axel Hecht]

Am 24.10.19 um 12:13 schrieb Henrik Skupin:

glob wrote on 23.10.19 17:56:


It's available now - make sure you're running the latest version by
running `moz-phab self-update`.


That's what I did yesterday, but as it looks like the self-update
actually didn't update my version to the latest MozPhab-0.1.55. I will
check soon with this version. Thanks!

Henrik



You need to run self-update twice to move over to the pip version.

Also, make sure to not run it while in a virtualenv like I did. 
Otherwise you end up uninstalling and installing it from scratch ;-)


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

Suggesting reviewers (was: Re: Using MozPhab without Arcanist)

[Andreas Tolfsen]

Emilio and Emma brings up an important barrier to outside contribution
here.

Also sprach Emilio Cobos Álvarez:

> On 10/23/19 10:24 PM, Emma Humphries wrote:
>> Will this make it easier for non-staff contributors to get their change
>> sets reviewed and landed?
>> What else should we be doing for that.
>> I have some ideas I'm working on for views in Bugzilla to help with that so
>> that contributors can see what's going on, and where they can take action
>> to help.
> 
> Somewhat unrelatedly, I think the most common issue I see with new
> contributors is they failing to set a reviewer. That means that
> their patch goes completely unnoticed... In that case not sure what
> can help, other than some of us noticing :/
> 
> I'm sure this is not a new problem though... That being said, it's
> a legit use-case, IMO, to update a WIP patch to phabricator without
> a reviewer, for example, to avoid spamming...
> 
> Maybe tools like moz-phab could suggest reviewers, or have a warning
> for the "no reviewers" case?


Patches submitted without reviewers has indeed been a recurring
problem since long before Phabricator.  I wonder, though, if we
could leverage Phabricator and the seeming convergence towards
review groups (or “shared review queues”) to improve the situation.

In the run-up to moving from MozReview to Phabricator, we had the
exact same discussion on this list about what problems outside
contributors face.  Not knowing to flag reviewers or not knowing
who to ask for review, and as a consequence our failure to respond
in a timely manner, is at least in my experience one of the reasons
that turn contributors away.

With Herald, Phabricator has quite a powerful system for filtering
and taking action on incoming diffs.  This is currently restricted
to personal use, so I can for example only add myself individually
as reviewer.

Over the last year many components have started using review groups,
e.g. hash tags such as “r=#remote-protocol-reviewers” and
“r=firefox-build-system-reviewers” to spread the review load more
evenly.  This makes Phabricator diffs turn up in the review queue
for everyone who’s a member of that group.  In the modules I’m owner
of, this has been an unreserved success.

Would it be possible to set up a “global” rule in Phabricator so
that a review group could always be added as reviewer based on a
filtering rule?

If this is possible it would make a decisively better first-time
experience than being told to “go read the commit log and find out
who touched the code last”, as I were told when I started contributing
seven years ago.

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

Re: C++ standards proposal for a embedding library

[Henri Sivonen]

On Thu, Oct 24, 2019 at 12:30 PM Gijs Kruitbosch
 wrote:
>  From experience, people seriously underestimate how hard this is -
> things like "I want a URL bar" or "I want tabs / multiple navigation
> contexts and want them to interact correctly" or "users should be able
> to download files and/or open them in helper apps cross-platform" are
> considerably less trivial than most people seem to assume, and even as
> Mozilla we have (perhaps embarrassingly) repeatedly made the same /
> similar mistakes in these areas when creating new "embedders" from
> scratch (Firefox for iOS, FirefoxOS, the various Android browsers), or
> have had to go over all our existing separate gecko consumers to adjust
> them to new web specs (most recent example I can think of is same site
> cookies, for instance, which requires passing along origin-of-link
> information for context menu or similar affordances), which is
> non-trivial and of course cannot happen without embedding API
> adjustments.

The Mozilla cases are harder, because the applications we build around
Web engines are Web browsers. My understanding (which may be wrong!)
is that the purpose of the C++ proposal isn't to enable creating Web
browsers around the API but to use the API to render the GUI for a
local C++ app whose primary purpose isn't to browse the Web, so I
assume "I want a URL bar" is the opposite of what the proposal is
after.

But even so, the proposal is inadequate in addressing questions like
multiple windows and various issues related to loading content from
the network as opposed to content from the app's own URL scheme that
maps to a stream produced by the C++ app internals. And its inadequate
for even the app-internal URL scheme: It looks like the app-internal
URL scheme is expected to map a URL to a stream of bytes as opposed to
a Content-Type and a stream of bytes.

--
Henri Sivonen
hsivo...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using MozPhab without Arcanist

[Henrik Skupin]

glob wrote on 23.10.19 17:56:

> It's available now - make sure you're running the latest version by
> running `moz-phab self-update`.

That's what I did yesterday, but as it looks like the self-update
actually didn't update my version to the latest MozPhab-0.1.55. I will
check soon with this version. Thanks!

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

Re: C++ standards proposal for a embedding library

[Gijs Kruitbosch]

Is there some visibility into the feedback by other participants (esp. 
other browser vendors) and why they think this is a good idea? What are 
the arguments *for* this thing, and have they engaged with our arguments 
against at all?


As a desktop Firefox person, "embedding" Gecko and providing UI on top 
is at some level what we do - with the added bonus that we can change 
Gecko to suit us if necessary (a luxury embedders generally do not have).


From experience, people seriously underestimate how hard this is - 
things like "I want a URL bar" or "I want tabs / multiple navigation 
contexts and want them to interact correctly" or "users should be able 
to download files and/or open them in helper apps cross-platform" are 
considerably less trivial than most people seem to assume, and even as 
Mozilla we have (perhaps embarrassingly) repeatedly made the same / 
similar mistakes in these areas when creating new "embedders" from 
scratch (Firefox for iOS, FirefoxOS, the various Android browsers), or 
have had to go over all our existing separate gecko consumers to adjust 
them to new web specs (most recent example I can think of is same site 
cookies, for instance, which requires passing along origin-of-link 
information for context menu or similar affordances), which is 
non-trivial and of course cannot happen without embedding API 
adjustments. That's before we've talked about the embedded code itself 
changing requirements (e10s, fission, sandboxing improvements, ...).


When looking at the objections our senior engineers had already raised 
earlier in this thread, I was struck by Ted's point about a module 
system - avoiding specifying a module system because "it's hard" (which 
I too don't disbelieve, fwiw), but instead trying to specify a web 
embedding API looks to me like the inverse of "better the devil you 
know" on the part of the C++ standard library folks - fundamentally, a 
module system is a more constrained thing than "please provide a 
complete API for interacting with the web".


Finally, I'll point out that in all this time, it seems (from searching 
the web, that is) the standard library committee has not specified a 
standard API for either sockets or HTTP(S) connections - a very very 
tiny subset of "web view", instead leaving everyone to integrate 
libcurl/neon/boost.asio/whatever as they see fit. It seems odd to go 
straight from "nothing" to "web view", and not start with the building 
blocks... Similar arguments could be made for xml/html parsing, JS 
engine support, CSS parsing, layout, etc.


(apparently there is/was a networking/socket (but not http/https - or 
even tls itself) proposal but afaict it hasn't been integrated in any of 
the finished standards so far?)


~ Gijs


On 22/10/2019 21:54, Botond Ballo wrote:

Hi folks,

I wanted to give an update on the "web_view" C++ standard library proposal.

I have relayed the feedback received on this thread on multiple
occasions, and our concerns about this proposal as a browser
implementer have been noted by the committee. However, the proposal
has been received positively by other participants of the committee,
including other browser vendors, and is continuing to be developed and
reviewed. While it's still at an early stage (still in front of the
Library Evolution Incubator group), it is being actively developed and
the proposed API is becoming more fleshed out.

Given that, would anyone be interested in reviewing the proposed API
and providing feedback on its design? I feel like the committee would
be receptive to constructive technical feedback, and as a group with
experience in developing embedding APIs, we are in a particularly good
position to provide such feedback.

The latest draft of the proposal can be found here:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1108r4.html

Thanks!
Botond

On Wed, Jul 18, 2018 at 12:45 PM Botond Ballo  wrote:


Hi everyone,

With the proposal for a standard 2D graphics library now on ice [1],
members of the C++ standards committee have been investigating
alternative ways of giving C++ programmers a standard way to write
graphical and interactive applications, in a way that leverages
existing standards and imposes a lower workload on the committee.

A recent proposal along these lines is for a standard embedding
facility called "web_view", inspired by existing embedding APIs like
Android's WebView:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1108r0.html

As we have some experience in the embedding space here at Mozilla, I
was wondering if anyone had feedback on this embedding library
proposal. This is an early-stage proposal, so high-level feedback on
the design and overall approach is likely to be welcome.

Thanks!
Botond

[1] 
https://botondballo.wordpress.com/2018/06/20/trip-report-c-standards-meeting-in-rapperswil-june-2018/


___
dev-platform mailing list
dev-platform@lists.mozilla.org

Re: To what extent is sccache's distributed compilation usable?

[Marcos Caceres]

On Thursday, October 24, 2019 at 6:46:08 AM UTC+11, Christopher Manchester 
wrote:
> As announced in this week's project call, sccache-dist schedulers have been
> deployed to mozilla offices, and those with hardware available can enroll
> servers based on the documentation here
> .

Just a reminder to not forget about us remotees! We are dying out here with 1+ 
hour compile times so anything would really help (even 20-20% improvement would 
go a long way). A lot of us have spare old macs, and if we can put them to good 
use with this, that would be amazing.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform