Re: Triage Plan for Firefox Components

[Nicholas Alexander]

Emma,

On Tue, Apr 5, 2016 at 5:27 PM, Emma Humphries  wrote:

> It's been a week since I asked for your comments on the plan for triage,
> thank you.
>
> I'm going reply to some general comments on the plan, and outline next
> steps.
>

I just want to say that I have been following this thread, and that I
haven't been a fan of the thrust of the initiative, but I really appreciate
this summation and your effort to be transparent.


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

Re: Triage Plan for Firefox Components

[Emma Humphries]

It's been a week since I asked for your comments on the plan for triage,
thank you.

I'm going reply to some general comments on the plan, and outline next
steps.

Ekt and others said that up to now, individual teams have owned how they
triage and prioritized bugs. Mozilla has made commitments to how we are
going to follow up with people filing bugs. Thus we need consistent
decisions across all the components that go into Firefox about bugs that we
can share back to non-Mozillans on bugs they file, so that we can get them
to contribute more high-quality bugs, and participate in other efforts in
support of the project and the Open Web. I'm aware I'm asking teams with
existing process to make a change, but it's for a global gain.

Several people pointed out all the fields in Bugzilla that have and could
be used to manage priorities, such as priority and rank. But we don't use
the priority field consistently across the project. I've asked for teams to
document how they use Priority,
https://wiki.mozilla.org/Bugmasters/Projects/Folk_Knowledge/Priority_Field,
and you'll see how that varies.

When I checked how the Priority field was used in Firefox-related
components, that distribution was:

--- 460,362
P1   14,304
P2   15,971
P3   37,933
P44,204
P52,913

The bulk of bugs in Firefox-related components are P3, most likely because
we have a bug filing form that defaults to P3 and that needs to be fixed if
it's still in use.

Having to make what seemed like snap-decisions on bugs was also a point of
concern, but that's something the proposal had a work around for, using
needinfo? to defer a triage decision on a bug until enough questions were
answered. And since we made a commitment to make decisions on bugs, we need
back pressure on untriaged bugs.

But from what I read, y'all are amenable to standardizing the priority
flag's use in Triage. Doing that would create a discontinuity in historical
data, but that's not an insurmountable problem, and we can document that
breakage for researchers using historical data.

So next step is a second proposal, simplified, using Priority to represent
triage decisions.

In addition, I'll want to remove several fields which are not useful, or
superfluous from the bug entry wizards. Priority is a field that should be
set by people triaging bugs, not entering them. We have a keyword
vocabulary which is more expressive than severity. And our bug entry forms
don't show the version affected, or the STR (steps to reproduce) flags
which means it's an extra edit to get the information relman needs into a
bug.

Thank you again for your time and consideration as we make Bugzilla and
Firefox better for everyone.

-- Emma Humphries


On Tue, Mar 29, 2016 at 1:07 PM, Emma Humphries  wrote:

> tl;dr
>
> In Quarter Two I'm implementing the work we’ve been doing to improve
> triage, make actionable decisions on new bugs, and prevent us from shipping
> regressions in Firefox.
>
> Today I’m asking for feedback on the plan which is posted at:
>
>
> https://docs.google.com/document/d/1FFrtS0u6gNBE1mxsGJA9JLseJ_U6tW-1NJvHMq551ko
>
> Allowing bugs to sit around without a decision on what we will do about
> them sends the wrong message to Mozillans about how we treat bugs, how we
> value their involvement, and reduces quality.
>
> The Firefox quality team (myself, Mike Hoye, Ryan VanderMeulen, Mark Cote,
> and Benjamin Smedberg) want to make better assertions about the quality of
> our releases by giving you tools to make clear decisions about which bugs
> must be fixed for each release (urgent) and actively tracking those bugs.
> What We Learned From The Pilot Program
>
> During the past 6 weeks, we have prototyped and tested a triage process
> with the DOM, Hello, and Developer Tools teams.
>
> Andrew Overholt, who participated in the pilot for the DOM team, said, “A
> consistent bug triage process can help us spread the load of watching
> incoming bugs and help avoid issues falling through the cracks."
>
> During the pilot, the DOM team uncovered critical bugs quickly so that
> people could be assigned to them.
>
> The pilot groups also found that the triage process needs to be fast and
> have tooling to make going through bugs fast. It’s easy to fall behind on
> triage for a component, but if you stay up to date it will take no more
> than 15 minutes a day.
>
> You can find the bugs we triaged during the pilot by looking for
> whiteboard tags containing ‘btpp-’.
>
> It is also important to have consistent, shared definitions for regression
> across components so triagers do not waste effort on mis-labeled bugs.
> Comments?
>
> I am posting this plan now for comment over the next week. I intend to
> finalize the triage plan for implementation by Tuesday, April 5th. Feedback
> and questions are welcome on the document, privately via email or IRC
> (where I’m emceeaich) or on the bugmast...@mozilla.org mailing list.
> Timeline
>
> January: finish finding component 

Re: Build System Project - Update from the last 2 weeks

[Mike Hommey]

On Tue, Apr 05, 2016 at 09:02:09PM +0100, David Burns wrote:
> Below is a highlight of all work the build peers have done in the last 2
> weeks as part of their work to modernise the build infrastructure.
> 
> Since the last report[1] a large number of improvements have landed in
> Mozilla Central.
> 
> The build system now lazily installs test files. Before, the build copied
> tens of thousands of test and support files. This could take dozens of
> seconds on Windows or machines with slow I/O. Now, the build system defers
> installing test files until they are needed there (e.g. when running tests
> or creating test packages). Furthermore, only the test files relevant to
> the action performed are installed. Mach commands running tests should be
> significantly faster, as they no longer examine the state of tens of
> thousands of files on every invocation.
> 
> After upgrading build machines to use VS2015, we have seen a decrease in
> build times[2] for PGO on Windows by around 100 minutes. This brings PGO
> times on Windows in line with that of PGO(Strictly speaking this is LTO)
> times on Linux.

Just a nit: strictly speaking Windows builds do PGO+LTO, Linux builds do
PGO, but not LTO.

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

Build System Project - Update from the last 2 weeks

[David Burns]

Below is a highlight of all work the build peers have done in the last 2
weeks as part of their work to modernise the build infrastructure.

Since the last report[1] a large number of improvements have landed in
Mozilla Central.

The build system now lazily installs test files. Before, the build copied
tens of thousands of test and support files. This could take dozens of
seconds on Windows or machines with slow I/O. Now, the build system defers
installing test files until they are needed there (e.g. when running tests
or creating test packages). Furthermore, only the test files relevant to
the action performed are installed. Mach commands running tests should be
significantly faster, as they no longer examine the state of tens of
thousands of files on every invocation.

After upgrading build machines to use VS2015, we have seen a decrease in
build times[2] for PGO on Windows by around 100 minutes. This brings PGO
times on Windows in line with that of PGO(Strictly speaking this is LTO)
times on Linux.

This work, coupled with the build promotion work[3] have reduced the time
it takes automation to release Firefox on Windows by over 10 hours.

We are continuing to remove configure, m4 code, and Makefiles from
mozilla-central. As mentioned in the previous status email, this will allow
us to replace the build backend with a more performant tool.

David

[1]
https://groups.google.com/d/msg/mozilla.dev.platform/IKRdGCjdN_Y/sK2QbXqmCAAJ

[2]
https://treeherder.mozilla.org/perf.html#/graphs?timerange=2592000=%5Bmozilla-inbound,04b9f1fd5577b40a555696555084e68a4ed2c28f,1%5D=%5Bmozilla-inbound,c0018285639940579da345da71bb7131d372c41e,1%5D=%5Bmozilla-inbound,65e0ddb3dc085864cbee77ab034dead6323a1ce6,1%5D

[3] https://rail.merail.ca/posts/release-build-promotion-overview.html
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Firefox Hello new data collection

[Joseph Lorenzo Hall]

On Tue, Apr 5, 2016 at 12:05 PM, Chris Hofmann  wrote:
> Thie passage in https://www.mozilla.org/en-US/privacy/firefox-hello/ also
> would lead me to believe that the contents of my communication with another
> user (including shared URLs) are encrypted (and would be private).
>
> We've just invested heavily in making this point and trying to make that
> association that encryption mean strong privacy and vice-versa.
> https://blog.mozilla.org/blog/2016/03/30/everyday-internet-users-can-stand-up-for-encryption-heres-how/

As an outside lurker on dev-platform but a big fan of Mozilla's data
stewardship folks, this is the core of the issue for me. WebRTC
conversations should be assumed to be highly private and any
exfiltration on the client without explicit opt-in is seems very
dangerous. I'm not saying it should never be done but it should be
very very important and done very very carefully. I don't get the
sense that this data is that crucial to innovative Hello features. You
could opt-in folks to the study just-in-time using tab sharing. I know
that clobbers the UX but if it's that important I think you need to
take that hit given the sensitivity of real-time comms.

-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
e: j...@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

CDT's annual dinner, Tech Prom, is April 6, 2016! https://cdt.org/annual-dinner
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to enable e10s by default when running tests locally

[Andrew Halberstadt]

This has now landed on central. The following suites are e10s by default
and require the --disable-e10s flag to run non-e10s:

* marionette
* mochitest (excluding chrome, a11y and android)
* reftest (excluding android)
* talos
* web-platform-tests

I also added some logging to marionette, mochitest and reftest both at
the start and end of the test run to make it easier to see whether e10s
was enabled or not (ctrl-f for e10s).

Please file bugs blocking bug 1243083 if you believe something is amiss.
Finally, bug 1261823 was filed to investigate a dual-mode that runs both
e10s and non-e10s. There is no eta at this time.

-Andrew

On 24/03/16 12:15 PM, Andrew Halberstadt wrote:

Bug 1243083 tracks enabling e10s by default when running tests locally.
I intend to do this for as many harnesses as possible unless someone
says otherwise.

The implication is that the --e10s flag will be renamed to
--disable-e10s. So you'll need to pass in --disable-e10s if you wish to
run without e10s enabled. This also means that tests that are skipped
with 'e10s' will no longer run by default locally. The hope is that this
will make it easier for devs to find and fix tests that are broken with
e10s enabled, as well as ensure that new tests work with e10s right out
of the gate. CI jobs will not be affected, only running locally.

One potential sticking point is mochitest-chrome. It currently does not
get run in e10s in CI, so local configuration should mirror this.
However, since --e10s is being removed, this means it would be
impossible to run mochitest-chrome in e10s without modifying source
files. Maybe this just needs some argparse hackery.

If you have any concerns or know of other suites that should explicitly
*not* be run with e10s enabled by default, please let me know.

Andrew


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

Re: Firefox Hello new data collection

[adam]

I think this should be abandoned in favour of an optional survey for Hello Users

05.04.2016, 17:06, "Chris Hofmann" :
> On Mon, Apr 4, 2016 at 3:01 AM, Romain Testard  wrote:
>
>>  Firefox Hello has its own privacy notice (details here
>>  ).
>
> Its unclear to me reading the follow through link to the
> TokBox Privacy Policy. -> https://tokbox.com/support/privacy-policy
>
> Does TokBox already have access to the contents of the messages and URLs
> that might have been shared?
>
> the tokbox policy says:
>
> The types of information collected include your name, e-mail address, and
> any other data you actively choose to provide.
>
> and leaves it vague about the definition of "other data you actively
> provide." Does that include shared URLs and message content?
>
> Thie passage in https://www.mozilla.org/en-US/privacy/firefox-hello/ also
> would lead me to believe that the contents of my communication with another
> user (including shared URLs) are encrypted (and would be private).
>
> We've just invested heavily in making this point and trying to make that
> association that encryption mean strong privacy and vice-versa.
> https://blog.mozilla.org/blog/2016/03/30/everyday-internet-users-can-stand-up-for-encryption-heres-how/
>
> How are we going to address the possible take away that some will have that
> we've just created a backdoor for parts (shared urls that are part of the
> message content) of the hello encrypted message channel if we turn this
> change on?
> ___
> 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: Firefox Hello new data collection

[Chris Hofmann]

On Mon, Apr 4, 2016 at 3:01 AM, Romain Testard  wrote:

>
> Firefox Hello has its own privacy notice (details here
> ).
>
>
Its unclear to me reading the follow through link to the
TokBox Privacy Policy.  ->  https://tokbox.com/support/privacy-policy

Does TokBox already have access to the contents of the messages and URLs
that might have been shared?

the tokbox policy says:

The types of information collected include your name, e-mail address, and
any other data you actively choose to provide.

and leaves it vague about the definition of "other data you actively
provide."   Does that include shared URLs and message content?

Thie passage in https://www.mozilla.org/en-US/privacy/firefox-hello/ also
would lead me to believe that the contents of my communication with another
user (including shared URLs) are encrypted (and would be private).

We've just invested heavily in making this point and trying to make that
association that encryption mean strong privacy and vice-versa.
https://blog.mozilla.org/blog/2016/03/30/everyday-internet-users-can-stand-up-for-encryption-heres-how/

How are we going to address the possible take away that some will have that
we've just created a backdoor for parts (shared urls that are part of the
message content) of the hello encrypted message channel if we turn this
change on?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Firefox Hello new data collection

[Randell Jesup]

>The privacy review bug is
>https://bugzilla.mozilla.org/show_bug.cgi?id=1261467.
>More details added below.
>> On 04/04/2016 10:01, Romain Testard wrote:
>>
>>> We would use a whitelist client-side to only collect domains that are
>>> part of the top 2000 domains (Alexa list of top domains). This
>>> prevents
>>> personal identification based on obscure domain usage.
>>>
>>
>> Mathematically, the combination of a set of (popular) domains shared could
>> still be uniquely identifying, especially as, AIUI, you will get the counts
>> of each domain and in what sequence they were visited / which ones were
>> visited in which session. It all depends on the number of unique users and
>> the number of domains they visit / share (not clear: see above). Because
>> the total number of Hello users compared with the number of Firefox users
>> is quite low, this still seems somewhat concerning to me. Have you tried to
>> remedy this in any way?
>>
>
>We are aggregating domain names, and are not storing session histories.
>These are submitted at the end of the session, so exact timestamps of any
>visit are not included.

There's been a bunch of surprises over the last few years where
"anonymized" data turned out to be de-anonymizable.  This is the sort of
data that feels like it could lead to surprises.  I think this would
need more looks by someone who actually understands that and where those
risks come from (not me).

There are added risks if you include the case of someone using our data
*and* data from one or more 3rd-party sites, and that's not easy to
reason about, which is why this needs careful consideration.

>> Finally, I am surprised that you're sharing this 2 weeks before we're
>> releasing Firefox 46. Hasn't this been tested and verified on Nightly
>> and/or other channels? Why was no privacy update made at/before that time?
>>
>
>We are shipping Hello through Go Faster. The Go Faster process allows us to
>uplift directly to Beta 46 directly since we're a system add-on
>(development was done about 2 weeks ago).
>Firefox Hello has its own privacy notice (details here
>).

Since the collection is not enabled currently anywhere, how known-stable
is it for beta?  Having the code in a disabled state safely is one
thing; having it known to be safe to turn on is another.

-- 
Randell Jesup, Mozilla Corp
remove "news" for personal email
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Platform engineering project of the month: Release Build Promotion

[raliiev]

Hello from Release Engineering!

Once a month we highlight one of our projects to help the Mozilla community 
discover a useful tool or an interesting contribution opportunity.

This month's project is Release Build Promotion.


What is Release Build Promotion?

Release build promotion (or "build promotion", or "release promotion" for 
short), is the latest release pipeline for Firefox being developed by Release 
Engineering at Mozilla.

Release build promotion starts with the builds produced and tested by CI (e.g. 
on mozilla-beta or mozilla-release). We take these builds, and use them as the 
basis to generate all our l10n repacks, partial updates, etc. that are required 
to release Firefox. We "promote" the CI builds to the release channel.


How is this different?

The previous release pipeline also started with builds produced and tested by 
CI. However, when it came time to do a release, we would create an entirely new 
set of builds with slightly different build configuration. These builds would 
not get the regular CI testing.

Release build promotion improves the process by removing the second set of 
builds. This drastically improves the total time to do a release, and also 
increases our confidence in our products since we now are shipping exactly 
what's been tested. We also improve visibility of the release process; all the 
tasks that make up the release are now reported to Treeherder along with the 
corresponding CI builds.


Some figures

One of the major reasons of this project was our release end-to-end times. I 
pulled some data to compare:

- One of the Firefox 45 betas took almost 12 hours
- One of the Firefox 46 betas took less than 3 hours

You can read more about it on my blog post:

https://rail.merail.ca/posts/release-build-promotion-overview.html

Feedback and ideas are always welcome!

-- 
Rail - on behalf of the Release Engineering team.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Triage Plan for Firefox Components

[Justin Dolske]

A few comments, although I think others have touched on some of this
already.

I think my biggest concern is that this is conflating triage and
prioritization, which complicates things and introduces ambiguity. For
example, what would it even mean to have a "triage: fix-now" bug that's
also a P5? I'd much rather leave prioritization to the priority field. I'm
similarly dubious about the value of "not-urgent" and "wishlist". In part
because those also imply priorities, but also because this phrasing seems
like just kicking the can down the road on "making a decision".

It would seem simpler to just have a triage +/-/? flag to indicate if a
decision on triage has been made. Although we're still kind of tap-dancing
around what to do with the inevitable pile of "we just won't be able to fix
this soon bugs" -- I'm not sure a subtle triage flag effectively
communicates intent to people that don't live inside Bugzilla like we do.
It wouldn't be any worse than the status quo (and so is fine to trial), but
it should really just be a new status/resolution... The existing "WONTFIX"
and "INVALID" often convey the wrong meaning, a more accurate (and
gentler!) "DEFERRED" or "INACTIVE" or $BIKESHED_HERE is something I'd like
to see for this common condition.

I don't really understand the 3-month auto-timeout of bugs back to an
untriaged state. This seems like it's just creating work and makes Bugzilla
annoying. Nor is a one-size-fits all solution right here -- large /
long-term and small / short-term project areas will have different needs.
Grooming the list of triaged, prioritized bugs is important for teams to
do, and we should encourage them to do so, but starting off with this being
automatic seems premature.

I'm also concerned about bolting on yet more UI, which makes Bugzilla even
_more_ obtuse and complicated. But given all the feedback on the current
proposal, I suppose it's not worth commenting on here because I presume
this would all change anyway. This also seems like it should just be a
separate project.

Justin


On Tue, Mar 29, 2016 at 1:07 PM, Emma Humphries  wrote:

> tl;dr
>
> In Quarter Two I'm implementing the work we’ve been doing to improve
> triage, make actionable decisions on new bugs, and prevent us from shipping
> regressions in Firefox.
>
> Today I’m asking for feedback on the plan which is posted at:
>
>
> https://docs.google.com/document/d/1FFrtS0u6gNBE1mxsGJA9JLseJ_U6tW-1NJvHMq551ko
>
> Allowing bugs to sit around without a decision on what we will do about
> them sends the wrong message to Mozillans about how we treat bugs, how we
> value their involvement, and reduces quality.
>
> The Firefox quality team (myself, Mike Hoye, Ryan VanderMeulen, Mark Cote,
> and Benjamin Smedberg) want to make better assertions about the quality of
> our releases by giving you tools to make clear decisions about which bugs
> must be fixed for each release (urgent) and actively tracking those bugs.
> What We Learned From The Pilot Program
>
> During the past 6 weeks, we have prototyped and tested a triage process
> with the DOM, Hello, and Developer Tools teams.
>
> Andrew Overholt, who participated in the pilot for the DOM team, said, “A
> consistent bug triage process can help us spread the load of watching
> incoming bugs and help avoid issues falling through the cracks."
>
> During the pilot, the DOM team uncovered critical bugs quickly so that
> people could be assigned to them.
>
> The pilot groups also found that the triage process needs to be fast and
> have tooling to make going through bugs fast. It’s easy to fall behind on
> triage for a component, but if you stay up to date it will take no more
> than 15 minutes a day.
>
> You can find the bugs we triaged during the pilot by looking for
> whiteboard tags containing ‘btpp-’.
>
> It is also important to have consistent, shared definitions for regression
> across components so triagers do not waste effort on mis-labeled bugs.
> Comments?
>
> I am posting this plan now for comment over the next week. I intend to
> finalize the triage plan for implementation by Tuesday, April 5th. Feedback
> and questions are welcome on the document, privately via email or IRC
> (where I’m emceeaich) or on the bugmast...@mozilla.org mailing list.
> Timeline
>
> January: finish finding component responsible parties
>
> February: pilot review of NEW bugs with four groups of components, draft
> new process
>
> Now: comment period for new process, finalize process
>
> Q2: implement new process across all components involved in shipping
> Firefox
> Q3: all newly triaged bugs following the new process
>
> -- Emma Humphries, Bugmaster
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Upcoming SSH Host Key Rotation for hg.mozilla.org

[Onno Ekker]

Op 5-4-2016 om 3:09 schreef Philip Chee:
> On 04/04/2016 23:52, Gregory Szorc wrote:
>> We also changed the SSH server config to only support the "modern" set of
>> ciphers, MACs, algorithms, etc from
>> https://wiki.mozilla.org/Security/Guidelines/OpenSSH#Modern. If you are
>> running an old SSH client, it may not be able to connect.
>>
>> If you encounter problems connecting, complain in #vcs with a link to
>> pastebinned `ssh -v` output so we can see what your client supports so we
>> may consider adding legacy support on the server as a stop-gap. But
>> upgrading your SSH client to something that supports modern crypto is
>> highly preferred. More and more Mozilla systems will be adopting these
>> "modern" SSH server settings. So you'll have to upgrade sometime.
> 
> I'm using TortoiseHg whichh uses PuTTY and PLINK internally. I've
> deleted the mozilla host key and accepted the new one.
> 
> Now I can't push to comm-central via TortoiseHg. I can't push directly
> via hg.exe either. Putty error message is uninformative.
> 
> Phil
> 
> 

I had my old SSH-key not only stored as hg.mozilla.org, but also as
numeric ip-address, which prevented the new one from working correctly.
Maybe something similar also happens for you?
Check your ~/.ssh/known_hosts file.

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