Re: [IMPORTANT] Please send feature technical documents for Firefox 68 by April 12

[Tania Maity]

Hi,

Currently, we are in the week#4 of Fx68 release. As I mentioned in my
previous email, feature documentation is due this Friday, April 12th. At
this point, below desktop features are still pending documentation.


Feature Name

Feature Owner

Engineering Team

ETP

Arthur Edelstein

Security

Bug 1525086 - [Mac] Start the RDD sandbox earlier

Haik Aftandilian

Platform Integration

Bug 1498742 [Mac] Start the GMP sandbox earlier

Haik Aftandilian

Platform Integration


For the following features, we've received some information however, we are
still waiting for many details as we've asked in our Feature Technical
Guideline document.


Feature Name

Feature Owner

Engineering Team

Stub installers for partner builds

Romain Testard

Platform Integration

MacOS pkg installer bundle

Romain Testard

Enterprise

FxA Toolbar Menu Telemetry

Alex Davis

Firefox Accounts

You can either make a copy of the Guideline document
and
share the pending information with the QA owners or you can add details to
your existing project documents.

I want to highlight that past due features will be called out next week and
by default, they will be deferred to the next release. Request for an
exception must have approvals from the head of engineering AND product.

If you have any questions please feel free to reach out to the QA team.

Thanks,

Tania

On Mon, Apr 8, 2019 at 4:43 PM Tania Maity  wrote:

> Hi,
>
> Just a reminder to everyone that the Feature technical documentation for
> Firefox 68 Release is due this Friday, April 12th. Any delay in
> submitting Feature technical documentation
> 
> will significantly impact QA’s ability to plan and test in Nightly and/or
> Beta cycle.
>
> I would request you to review this document
> 
> shared earlier to know more about this *deadline* and *exceptions.*
>
> Thanks,
> Tania
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate - linux32 tests starting with Firefox 69

[Joel Maher]

Thanks everyone for your comments.

If we were to run linux32 tests in whole on mozilla-central only that would
result in about half of the load we see from linux32 today and about 1
backfill a week (given that most unique linux32 regressions result in test
disabling).  That alone would be a good savings of time, money, and
reduction of intermittents.

I would like to see what others think about keeping the platform supported
on trunk vs letting it ride the trains to beta where it would live until
near the end of 2020.  I assume a discussion about what unique features and
code will help determine what level of support we want for tests/builds of
linux32.


On Wed, Apr 10, 2019 at 12:53 PM Bobby Holley  wrote:

> I'd like to refocus this thread a bit around Jed's question, because it
> gets to the core of the issue.
>
> The proposal argues that test results for linux32 closely track those for
> linux64, and that this duplication is expensive. If that's the only
> problem, we could solve it by keeping linux32 as a tier-1 platform, but
> just running the tests much less frequently. This would require
> occasionally backfilling jobs when something does break, but that should be
> rare.
>
> There is a separate question of whether it is expensive to _engineer_ for
> linux32, and whether we should drop support on those grounds (a la Windows
> XP and non-SSE2). So far, the only linux32-specific engineering cost that
> has been raised is linux32-specific sandboxing code. Is this a significant
> maintenance burden? Are there other large areas of the code that are
> linux32-specific?
>
>
>
> On Mon, Apr 8, 2019 at 4:20 PM Jed Davis  wrote:
>
> > jma...@mozilla.com writes:
> >
> > > As our next ESR is upcoming, I would like to turn off linux32 on
> > > Firefox 69 and let it ride the trains and stay on 68 ESR.  This will
> > > allow builds/tests to be supported with security updates into 2021.
> >
> > Does this mean that Linux on 32-bit x86 is being demoted to Tier 3, like
> > (non-Android) Linux on other uncommon architectures?  Have we identified
> > a maintainer to take responsibility for testing and working with us to
> > fix regressions?  I don't see how it can remain Tier 1 without CI
> coverage.
> >
> > Also, will it still be possible to explicitly request linux32 on Try
> > runs?  Our cross-building story is not good, and being able to use Try
> > for this helpful for avoiding regressions and testing changes to
> > arch-dependent code.
> >
> > For context, I'm the module owner for Linux sandboxing, and we have to
> > deal with low-level details of the system call ABI, and as a result
> > there is nontrivial code used only for linux32 that I'm responsible for.
> >
> > --Jed
> > ___
> > 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: Intent to deprecate - linux32 tests starting with Firefox 69

[Bobby Holley]

I'd like to refocus this thread a bit around Jed's question, because it
gets to the core of the issue.

The proposal argues that test results for linux32 closely track those for
linux64, and that this duplication is expensive. If that's the only
problem, we could solve it by keeping linux32 as a tier-1 platform, but
just running the tests much less frequently. This would require
occasionally backfilling jobs when something does break, but that should be
rare.

There is a separate question of whether it is expensive to _engineer_ for
linux32, and whether we should drop support on those grounds (a la Windows
XP and non-SSE2). So far, the only linux32-specific engineering cost that
has been raised is linux32-specific sandboxing code. Is this a significant
maintenance burden? Are there other large areas of the code that are
linux32-specific?



On Mon, Apr 8, 2019 at 4:20 PM Jed Davis  wrote:

> jma...@mozilla.com writes:
>
> > As our next ESR is upcoming, I would like to turn off linux32 on
> > Firefox 69 and let it ride the trains and stay on 68 ESR.  This will
> > allow builds/tests to be supported with security updates into 2021.
>
> Does this mean that Linux on 32-bit x86 is being demoted to Tier 3, like
> (non-Android) Linux on other uncommon architectures?  Have we identified
> a maintainer to take responsibility for testing and working with us to
> fix regressions?  I don't see how it can remain Tier 1 without CI coverage.
>
> Also, will it still be possible to explicitly request linux32 on Try
> runs?  Our cross-building story is not good, and being able to use Try
> for this helpful for avoiding regressions and testing changes to
> arch-dependent code.
>
> For context, I'm the module owner for Linux sandboxing, and we have to
> deal with low-level details of the system call ABI, and as a result
> there is nontrivial code used only for linux32 that I'm responsible for.
>
> --Jed
> ___
> 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: Intent to remove "-e10s" from treeherder group symbols and task labels

[Andrew Halberstadt]

I had about 5 independent suggestions of "-sp" and I agree that it is much
better than "-fc". But another idea that came out of these conversations
was "1proc" which also ticks all the boxes (only being a tiny bit longer
than "e10s") and being even clearer than "-sp". I think I'll go with that
one. Thanks to everyone for all the feedback!

-Andrew

On Wed, Apr 10, 2019 at 4:36 AM Jonathan Kew  wrote:

> On 09/04/2019 20:44, Andrew Halberstadt wrote:
> > 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) People who use "e10s" in their |mach try fuzzy| queries out of muscle
> > memory (or in saved presets) will accidentally select the exact opposite
> of
> > what they want.
> > 3) For new contributors "e10s" is a code word anyway. It's just now they
> > need to learn "fc" instead of "e10s".
> >
> > None of those are terribly compelling, but it's still enough to make me
> > prefer "-fc".
>
> I think (1) and (2) here are good points; I'm less convinced by (3).
> Yes, e10s is a code word, but it's one that is pretty long-established
> and pervasive in the project and surrounding documentation (it even
> shows up in the names of about:config settings). It appeared in
> treeherder UI *because* it was a well-established term within the project.
>
> The proposed -fc suffix, on the other hand, seems gratuitously cryptic.
> If it had suddenly appeared in treeherder, I'd have been totally
> clueless as to its meaning; and even after seeing the announcement here,
> it feels like an artificial label that's trying a bit too hard to come
> up with a "clever" code where none is needed. It's not like we're
> starting with a standard multi-process configuration, and launching a
> grand "Fuel Cell" project that aims to merge the processes together.
>
> How about suffixing these jobs with -sp for "Single Process"? That would
> be a lot more transparent, IMO.
>
> JK
> ___
> 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

PSA: Bot automatically assigning components to Untriaged (and some General) bugs

[Marco Castelluccio]

Hello all,
I just wanted to notify you that since a few weeks ago, our release mgmt
bot has started automatically assigning components to untriaged bugs.
The results look good so far, so we are going to keep it enabled.

The bot is using machine learning to select a component, so it isn't
100% perfect. If you see a mistake, please correct it, and the bot will
learn from its mistakes.

We are assigning product/component to bugs from 'Untriaged'.

We are also assigning product/component to bugs from 'General', which is
sometimes used as a catch-all component, as in many cases a better
component can be found. This is of course much more difficult than the
Untriaged case, so we apply the change only when the bot "feels"
confident enough.

More information about the bot at
https://hacks.mozilla.org/2019/04/teaching-machines-to-triage-firefox-bugs/.

Thanks,
Marco.

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

Re: Intent to remove "-e10s" from treeherder group symbols and task labels

[Jonathan Kew]

On 09/04/2019 20:44, Andrew Halberstadt wrote:

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) People who use "e10s" in their |mach try fuzzy| queries out of muscle
memory (or in saved presets) will accidentally select the exact opposite of
what they want.
3) For new contributors "e10s" is a code word anyway. It's just now they
need to learn "fc" instead of "e10s".

None of those are terribly compelling, but it's still enough to make me
prefer "-fc".


I think (1) and (2) here are good points; I'm less convinced by (3). 
Yes, e10s is a code word, but it's one that is pretty long-established 
and pervasive in the project and surrounding documentation (it even 
shows up in the names of about:config settings). It appeared in 
treeherder UI *because* it was a well-established term within the project.


The proposed -fc suffix, on the other hand, seems gratuitously cryptic. 
If it had suddenly appeared in treeherder, I'd have been totally 
clueless as to its meaning; and even after seeing the announcement here, 
it feels like an artificial label that's trying a bit too hard to come 
up with a "clever" code where none is needed. It's not like we're 
starting with a standard multi-process configuration, and launching a 
grand "Fuel Cell" project that aims to merge the processes together.


How about suffixing these jobs with -sp for "Single Process"? That would 
be a lot more transparent, IMO.


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

Re: Intent to deprecate - linux32 tests starting with Firefox 69

[Henri Sivonen]

On Tue, Apr 9, 2019 at 6:05 PM Gian-Carlo Pascutto  wrote:

> On top of that, we know that not all distros have telemetry enabled and
> so we won't be counting those either (Debian is the largest).

We get telemetry from Ubuntu, Fedora, and Arch (subject to choices
made by the user). I'm not particularly worried about Debian, because
x86_64 (as amd64) has had prominent (unlike Ubuntu; see below)
availability from Debian pretty much for as long as x86_64 hardware
has been available. But in any case, not enabling telemetry means not
having representation in data-driven decision making.

> At least current Ubuntu and Ubuntu LTS are still available in 32-bit:
> https://www.ubuntu.com/download/alternative-downloads
>
> Ubuntu is our largest userbase (with telemetry...)

The latest and the latest LTS are offered for 32-bit x86 only as
netboot installers, and the latest LTS also as an upgrade from an
earlier version, so Ubuntu now positions 32-bit x86 as more obscure
than s390x, ppc64el, aarch64, and armv7hf. Ubuntu has already disabled
automatic updates to 18.10 for 32-bit x86, because the expectation is
that 18.04 will be the longest-supported release for 32-bit x86.

I think the main problem with Ubuntu is that Ubuntu promoted 32-bit
x86 downloads to users who didn't have the expertise to seek the
x86_64 version for way longer than they, in my opinion, should have
(though, in fairness, at that time, Mozilla also was promoting 32-bit
x86 downloads over 64-bit). Users who installed Ubuntu at that time
may have gotten a 32-bit distro even if the hardware would work just
fine with the 64-bit version, and there are no upgrades from 32-bit to
64-bit other than reinstall. Probably more Canonical's job than ours
to communicate to those users that they should do a 64-bit reinstall.

(In terms of security support from the Ubuntu repos, I find the
situation for architectures that aren't tier-1 for us a bit
concerning. Compare
https://packages.ubuntu.com/search?suite=disco=names=firefox
with 
https://packages.ubuntu.com/search?suite=cosmic=names=firefox
. Despite 32-bit x86 having been demoted below s390x, ppc64el,
aarch64, and armv7hf in terms of distribution images, 32-bit x86 gets
better security support in the Ubuntu repos than s390x, ppc64el,
aarch64, and armv7hf. So does security support in Ubuntu repos depend
on our tier positioning or to Ubuntu's own positioning?)

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

Re: Proposed W3C Charters: Internationalization (i18n) Working Group and Interest Group

[Henri Sivonen]

On Tue, Apr 9, 2019 at 11:13 PM L. David Baron  wrote:
>
> 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.w3.org/Archives/Public/public-new-work/2019Apr/0004.html
> > >   diff from previous charter: 
> > > https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FInternational%2Fcore%2Fcharter-2016.html=https%3A%2F%2Fwww.w3.org%2F2019%2F04%2Fproposed-i18n-wg-charter.html
> > >
> > >   Internationalization (i18n) Interest Group
> > >   https://www.w3.org/2019/04/proposed-i18n-ig-charter.html
> > >   https://lists.w3.org/Archives/Public/public-new-work/2019Apr/0004.html
> > >   diff from previous charter: 
> > > https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FInternational%2Fig%2Fcharter-2016.html=https%3A%2F%2Fwww.w3.org%2F2019%2F04%2Fproposed-i18n-ig-charter.html
> > >
> > > Mozilla has the opportunity to send comments or objections through
> > > Friday, May 3.
> > >
> > > Please reply to this thread if you think there's something we should
> > > say as part of this charter review, or if you think we should
> > > support or oppose it.  (Absent specific comments, I'd be inclined to
> > > support the charters, because I think the i18n work at W3C has been
> > > generally effective.)
> >
> > Is the WG expected to continue to issue revisions to
> > https://www.w3.org/TR/charmod-norm/ ? The document itself suggests
> > sending comments via GitHub issues. I don't see a charter item that
> > clearly covers the maintenance of this document. Should we ask for an
> > item that ensures that the group is explicitly chartered to continue
> > to maintain this document?
>
> I expect the wording at the start of section 2.1 (Normative
> Specifications) that says:
>
>   The formal documents produced by the Working Group are guidelines,
>   best practices, requirements, and the like. These are best
>   published as Working Group Notes.
>
> probably covers this.  Or does this document not fit within that
> description?

Oops. Sorry. Yes, those sentences cover it. Thanks. (I searched for
the case-insensitive string "note", but somehow I managed to miss the
second sentence you quoted.)

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