Re: Removal of B2G from mozilla-central

[Nicholas Nethercote]

A comparison point: I opened
https://bugzilla.mozilla.org/show_bug.cgi?id=1264155 a while back
about removing widget/uikit/ -- which is used by the old iOS port of
Firefox -- and others disagreed so I let it slide. So there's
precedent for little-used/unused widget code hanging around. (Whether
or not that's a good precedent is another matter...)

Nick

On Tue, Oct 4, 2016 at 10:22 AM, Gregory Szorc  wrote:
> On Mon, Oct 3, 2016 at 3:20 PM, Gabriele Svelto  wrote:
>
>> > Respectively, it seems like these requests were ultimately not included
>> > in the final decision.
>>
>> I would like to know why; I think that's not much to ask. I would also
>> like to know why this decision was made without any public discussion.
>> As I've pointed out the removal of another widget was discussed on this
>> list only a few months ago.
>>
>> The gonk widget is made of roughly 60K lines of code out of the 14
>> million lines of our codebase is made of[1]. It's not a large number
>> both in absolute and relative terms and also well contained so why can't
>> it be kept around?
>>
>
> https://dxr.mozilla.org/mozilla-central/search?q=gonk seems to contradict
> your assertion that gonk is well-contained. There are literally references
> to gonk throughout the tree. Every reference that isn't self-contained
> introduces cognitive dissonance when someone encounters it. They have to
> consider the existence of gonk when reading and changing the code. This
> makes changing code harder and undermines the ability for Firefox/Gecko to
> "evolve quickly." Even the very presence of unused, self-contained code
> (like gonk widgets) adds overhead because it can make common operations
> like refactoring more time consuming. And if someone breaks the code
> (because it isn't used) and a bug gets filed to track that, now you've
> introduced overhead for people to triage said bugs. These problems don't
> exist when the code doesn't exist. That's why we should aggressively delete
> unused and unsupported code.
> ___
> 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: Removal of B2G from mozilla-central

[Gregory Szorc]

On Mon, Oct 3, 2016 at 3:20 PM, Gabriele Svelto  wrote:

> > Respectively, it seems like these requests were ultimately not included
> > in the final decision.
>
> I would like to know why; I think that's not much to ask. I would also
> like to know why this decision was made without any public discussion.
> As I've pointed out the removal of another widget was discussed on this
> list only a few months ago.
>
> The gonk widget is made of roughly 60K lines of code out of the 14
> million lines of our codebase is made of[1]. It's not a large number
> both in absolute and relative terms and also well contained so why can't
> it be kept around?
>

https://dxr.mozilla.org/mozilla-central/search?q=gonk seems to contradict
your assertion that gonk is well-contained. There are literally references
to gonk throughout the tree. Every reference that isn't self-contained
introduces cognitive dissonance when someone encounters it. They have to
consider the existence of gonk when reading and changing the code. This
makes changing code harder and undermines the ability for Firefox/Gecko to
"evolve quickly." Even the very presence of unused, self-contained code
(like gonk widgets) adds overhead because it can make common operations
like refactoring more time consuming. And if someone breaks the code
(because it isn't used) and a bug gets filed to track that, now you've
introduced overhead for people to triage said bugs. These problems don't
exist when the code doesn't exist. That's why we should aggressively delete
unused and unsupported code.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removal of B2G from mozilla-central

[Gabriele Svelto]

> Respectively, it seems like these requests were ultimately not included
> in the final decision.

I would like to know why; I think that's not much to ask. I would also
like to know why this decision was made without any public discussion.
As I've pointed out the removal of another widget was discussed on this
list only a few months ago.

The gonk widget is made of roughly 60K lines of code out of the 14
million lines of our codebase is made of[1]. It's not a large number
both in absolute and relative terms and also well contained so why can't
it be kept around?

I'd also like to point out that as far as I know Mozilla has four times
the staff as when it was introduced, so I doubt that the effort of a few
people keeping it around as tier 3 would impact the organization much.

 Gabriele

[1] https://www.openhub.net/p/firefox



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removal of B2G from mozilla-central

[Justin Dolske]

On Fri, Sep 30, 2016 at 3:31 AM, Gabriele Svelto 
wrote:

>
> Since gonk is a widget on its own, during the internal discussions about
> it I - and others who worked on B2G - repeatedly asked for the gonk
> widget to be left in the code even after the removal of all the
> B2G-specific APIs (as a tier3 platform obviously).
>

Respectively, it seems like these requests were ultimately not included in
the final decision. The announcement was pretty clear about "Mozilla’s
Platform Engineering organization needs to remove all B2G-related code from
mozilla-central" and that the community "will need to fork Gecko and
proceed with development on their own, separate branch". Pending any
clarification of that decision, I should think a full removal of this code
would remain the default course of action.

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

upcoming meeting announcement - intermittent orange hacking

[jmaher]

Every 2 weeks on Friday at 9 PDT [1] we will be hosting a meeting to discuss 
intermittent oranges.  The format will be a chance for people with previous 
topics to relate status and findings, then the rest of the meeting discuss and 
surface ideas to consider investigating more.

Our topics for the October 7th meeting are:
* [jmaher] defining intermittent oranges (are there logical categories we can 
break failures into?)
* [gbrown] disabling unreliable tests (sheriffs point of view vs developers 
point of view, and what makes sense to ship a quality product)

Please consider joining us or reaching out to us to give input, share ideas and 
your perspective.

I do not plan to post ahead of every meeting, but I will mention in November 
where we are as well as options to learn more at an upcoming work week.

[1] https://wiki.mozilla.org/Auto-tools/Projects/Stockwell/Meetings
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Fwd: [TCW] Scheduled Tree Closing Maintenance Window 2016-10-08 06:00a PDT 9 hours

[Hal Wine]

Our usual Tree Closing Window is Saturday, Oct 8. This time, there is some
major work, so trees will be closed hard at the start at 0600 PT.

We hope to be able to switch to "soft close" around 1100 PT. "Soft Close"
means the trees are open, but there may be possible hickups, and it is up
to devs to sheriff their own jobs and retry as appropriate.

See below for further details.

-- Forwarded message --
From: m...@mozilla.com 
Date: Fri, Sep 30, 2016 at 10:31 AM
Subject: [TCW] Scheduled Tree Closing Maintenance Window 2016-10-08 06:00a
PDT 9 hours
To:


bcc:all

Start Date/Time: 2016-10-08 06:00a PDT
End date/time: 2016-10-08 15:00p PDT

*Impact to Users:*

   - Trees will be in hard close state for the beginning of the outage;  A
   decision will be made after DB patching is done to open the trees  to a
   soft close state

   -

   Possible brief interruption to services in SCL3 06:00-06:15a
   -

   Many systems will be patched  (both the database and application
   servers) - there will be very brief outages to mana, bugzilla, buildbot,
   single home internal sites, etc between at 08:00a and 13:00.  These are
   expected and should last < 10 min per site.  MOC will validate
   functionality of all sites.


Tracker Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1302784

List of work to be completed:


NA
need to reset the optic on border2.scl3 xe-1/1/0
NA
upgrade core1.releng to fix ssh problem
https://bugzilla.mozilla.org/show_bug.cgi?id=925238 Enable IPv6 for
proxy[1234].dmz.scl3 and proxy[12].dmz.phx1

Patch releng dns / dc proxies
https://bugzilla.mozilla.org/show_bug.cgi?id=1297935 purposely failover
fw1.releng.scl3 to collect data for Juniper
NA
shut down ISP link to Telia, to investigate the impact of reachability to
Mozilla's main AS
NA
Need to kernel patch and db upgrade mana, bugzilla, reviewboard
https://bugzilla.mozilla.org/show_bug.cgi?id=1292084 Need to kernel patch
generic, devtools, buildbot and treeherder clustsers
https://bugzil.la/1290275 Update and reboot 51 machines for Webops during
the TCW
https://bugzilla.mozilla.org/show_bug.cgi?id=1231186 Briefly enable service
checks on testing Nagios 4 host
https://bugzilla.mozilla.org/show_bug.cgi?id=1305855 Patch and reboot
admin1[ab].private.scl3
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[Firefox Desktop] Issues found: September 26th to September 30th

[Cornel Ionce]

Hi everyone,

Here's the list of new issues found and filed by the Desktop Release QA 
Team last week, *September 26 - September 30* (week 39).


Additional details on the team's priorities last week, as well as the 
plans for the current week are available at:


   https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus


*RELEASE CHANNEL*


*BETA CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1306247 
Crash in _platform_bzero$VARIANT$Haswell
Core
WebRTC
	YES 
 
	Randell Jesup 

1306299 
First transition to Simplify page will display no images no images
Toolkit
Printing
NO  NOBODY
1306298 
	Print preview window showing progress stuck when double clicking 
Simplify Page

Toolkit PrintingNO  NOBODY
1306297 
	[Ubuntu] Firefox is confused on what to display when fast double 
clicking Simplify Page

Toolkit PrintingNO  NOBODY
1306296 
Missing shortcut key to Simplify Page
Toolkit PrintingNO  NOBODY
1306295 
[Ubuntu] Layout issues while clicking Simplify page multiple times
Toolkit PrintingNO  NOBODY
1306294 
Restarting browser while Simplify Page mode on, restores 2 new empty 
tabs
Toolkit PrintingNO  NOBODY
1306293
 	Different 
keyboard actions does not work on Simplify Page/Print Preview

Toolkit PrintingNO  NOBODY
1306590 
Visual issues on https://www.reddit.com/
Core
Layout: Text
NO  NOBODY



*AURORA CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1305744 
	Twitter profile picture glitches when the page is scrolled in maximized 
window

Core
Layout
	YES 
 
	NOBODY

1306561 
	Restore Defaults button is enabled and has undesired effects on a clean 
profile using Aurora

Firefox
Theme
	YES 
 
	NOBODY

1306649 
Resize to inspector is limited on Mac
Firefox
Developer Tools: Inspector
YES  NOBODY



*NIGHTLY CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1305736 
[Ubuntu] Glitch appears when going on/off Fullscreen mode
Core
Audio/Video: Playback
	YES 
 
	NOBODY

1305945 
The 'Find' option is not working correctly while RDM is enabled
Firefox
Developer Tools: Responsive Design Mode
NO  NOBODY



*ESR CHANNEL*
none

Regards,
Cornel Ionce
Team Lead
SOFTVISION

The content of this communication is classified as SOFTVISION 
Confidential and Proprietary Information.


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

Re: Want to learn TLS certificate verification best practices

[Gervase Markham]

Hi Ben,

This question might be better off in mozilla.dev.tech.crypto.

On 30/09/16 23:00, Ben Cottrell wrote:
> I'm working on an (unfortunately closed-source) project that needs
> to closely approximate the behavior of an actual web browser, in
> the limited scope of making HTTPS connections and accurately warning
> about certificate problems.

You know about:
https://www.ssllabs.com/ssltest/
right? It seems like they have already done all the work you are
planning to do, including handshake simulation.

> 1. In as much detail as possible, what steps does Firefox take to
>verify certificates? If there's a formal engineering spec that
>describes the whole process, I'd love a pointer to it.

No, I don't think so, sorry. Read the code :-|

>Specifically, I'm interested in questions like: Does Firefox even
>bother with "traditional" CRLs, 

No, it doesn't.

> or does it rely entirely on OCSP
>and/or stapling from the server? What X.509 extensions does it pay
>attention to on the certificates? Does Firefox implement the
>entirety of RFC5280 section 6 or does it omit things like policy
>mapping and permitted subtrees? Does it use Authority Key
>Identifier / Subject Key Identifier, as the RFC suggests, *only* in
>cases where the issuer/subject DNs are ambiguous, or does it treat
>the key identifiers (if present) as the primary source of truth?

Many of these are questions about NSS, the security library we use,
hence my suggestion of asking elsewhere.

> 2. How bad is OpenSSL's certificate-verifying behavior, really? I know
>you folks felt like you had to write mozilla::pkix from scratch to
>get the quality you needed. And it's true that I haven't yet tried
>to make OpenSSL do OCSP, so I'm not sure yet how hard that will be.

I don't think just pinching OpenSSL's library was ever an option, but I
wasn't deep in those technical discussions. We don't use OpenSSL in
Firefox at all.

> I'd also be happy with pointers to best-practices type documents that
> you folks trust. What did the people who wrote mozilla::pkix read, as
> preparation for that project? 

That project was mostly coded by Brian Smith, who no longer works for
Mozilla, but can be found quite easily:
https://github.com/briansmith

Gerv

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