Re: Commit messages in Phabricator

[Piotr Zalewa]

Hi Emilio,

Landing using upcoming "Lando" will use the following format
(taken from
https://github.com/mozilla-conduit/lando-api/blob/master/landoapi/commit_message.py#L21)
:

```
 -  r=,r=



Differential Revision: 
```

"Test Plan" is describing the steps to test the patch by the reviewer.

"Subscribers" is a list of users author would like to subscribe to the
revision.

zalun

On Sun, Feb 11, 2018 at 9:57 PM Emilio Cobos Álvarez 
wrote:

> Hey,
>
> So I've been testing Phabricator for a while and I've noticed that the
> arc tool uses different formatting for the commit messages than what
> usually lands on mozilla-central.
>
> In particular I usually lay out my commits like:
>
> ---
> Bug XXX: Short summary. r=
>
> Long description, if needed.
> ---
>
> Arc wants to use something like:
>
> ---
> Short summary.
>
> Summary:
> Long description (I assume?).
>
> Test Plan: (what goes here?)
>
> Reviewers: 
>
> Subscribers: (what goes here?)
>
> Bug #: XXX
>
> Differential revision: https://phabricator.services.mozilla.com/D574
> ---
>
> I've been manually fixing them up before committing them so they have
> the usual format when landing.
>
> My question is: Are commits that are going to land to autoland from
> phabricator directly going to land with the new format?
>
> Should we keep fixing them up before pushing to autoland / inbound, or
> should we start pushing commits with the new commit message formatting?
>
> Also, knowing an answer for the (what goes here?) questions would be
> super-helpful.
>
> Thanks a lot!
>
>   -- Emilio
> ___
> 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 implement and ship navigator.webdriver

[Andreas Tolfsen]

Also sprach Andreas Tolfsen:

> Summary:
> I intend to implement and ship a new enumerable, configurable,
> read-only "webdriver" attribute on the Navigator object.  The
> attribute is true when the -marionette flag is passed to Firefox
> or the marionette.enabled preference is true.  Otherwise it is
> false.

We decided to also throw in a preference dom.webdriver.enabled that
controls the exposure of the navigator.webdriver attribute.  When
flipped to false it will remove the attribute.

I intend to land the patches on https://bugzil.la/1169290 soon.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Commit messages in Phabricator

[Eric Rescorla]

On Mon, Feb 12, 2018 at 6:09 AM, Boris Zbarsky  wrote:

> On 2/11/18 3:57 PM, Emilio Cobos Álvarez wrote:
>
>> Arc wants to use something like:
>>
>
> So from my point of view, having the bug# easily linked from various
> places where the short summary is all that's shown (pushlogs especially) is
> pretty useful.  It saves loading a bunch of extra things when trying to go
> from regression-range pushlogs to the relevant bugs


Yes, this does seem convenient. I imagine we could develop tooling to deal
with other locations, but probably better not to.

Instead, maybe we can arrange for Phab/Lando to put the bug #in the short
message, potentially also with r=

-Ekr


>
> -Boris
>
> ___
> 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: Commit messages in Phabricator

[Boris Zbarsky]

On 2/11/18 3:57 PM, Emilio Cobos Álvarez wrote:

Arc wants to use something like:


So from my point of view, having the bug# easily linked from various 
places where the short summary is all that's shown (pushlogs especially) 
is pretty useful.  It saves loading a bunch of extra things when trying 
to go from regression-range pushlogs to the relevant bugs


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

Re: Commit messages in Phabricator

[Gregory Szorc]

On Mon, Feb 12, 2018 at 6:09 AM, Boris Zbarsky  wrote:

> On 2/11/18 3:57 PM, Emilio Cobos Álvarez wrote:
>
>> Arc wants to use something like:
>>
>
> So from my point of view, having the bug# easily linked from various
> places where the short summary is all that's shown (pushlogs especially) is
> pretty useful.  It saves loading a bunch of extra things when trying to go
> from regression-range pushlogs to the relevant bugs


It's generally pretty easy to modify tooling to find linked bugs. We have a
shared Python module for parsing commit messages into useful metadata and
that's used by various tools for extracting bugs, reviewers, so they can be
rendered in various places (
https://hg.mozilla.org/hgcustom/version-control-tools/file/3743b6c62d05/pylib/mozautomation/mozautomation/commitparser.py).
And updating templating on hg.mozilla.org to render useful fields more
prominently is generally pretty turnkey. Please file bugs in the
hg.mozilla.org component if you want the display of things tweaked!

More to the point of the original question, there are several reasons why
we don't want to use Arcanist (`arc`) for Firefox development (and probably
more broadly at Mozilla). The initial comment in bug 1366401 records a lot
of them. The plan of record is to author a minimal client for submitting
reviews via Phabricator's HTTP API and to plumb that up to `mach` as
needed. This work isn't part of the Phabricator MVP, which is why the
Phabricator team hasn't worked on it.

If you use Mercurial, there is an alternative to Arcanist available today!
You can combine Mercurial's "phabricator" extension with a minimal wrapper
that Tom Prince wrote so it recognizes Mozilla's bug numbers and reviewer
annotations. Instructions are at
https://bugzilla.mozilla.org/show_bug.cgi?id=1366401#c4. This will likely
serve as the base for the eventual solution. It is probably less effort to
configure this than to install Arcanist. It is unsupported, but I think it
is better than using Arcanist.

Git users will likely have to wait until after the Phabricator MVP is
launched before there is staffing to work on a client. We kind of lucked
out that Mercurial had something that was almost drop-in ready for us to
consume and that is why there is a Mercurial alternative (i.e. this isn't
about prioritizing Mercurial over Git).

While I'm not working on either client implementation and am not part of
the Phabricator team, if someone wants to formalize the Mercurial or Git
clients in version-control-tools before the Phabricator team has time to
work on them, I'd be happy to review code or provide technical assistance.
Track things against bug 1366401 if you do any work.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Debugging Try server builds

[Ted Mielczarek]

If you've debugged builds from the try server in the past (or wanted to but 
found the process too difficult) I'd be interested to hear from you. 
Historically this has been a painful process with many manual steps[1], but 
thanks to some work done[2] by Peter Bengtsson on the new symbols.mozilla.org 
service we are now in a position where we should be able to make this much 
simpler. I've filed a bug[3] with some initial details and thoughts but I'd 
like to hear from people who have needed this in the past to make sure that we 
wind up with something that's useful to you.

The base assumption that I did not list in that bug is that we're not likely to 
make every try push upload symbols for every single build it does--that's a lot 
of data and I suspect that most people don't need it, so we'd be wasting 
resources for minimal gain. (We don't upload symbols to the symbol server for 
anything that's not a nightly or release build currently--builds we ship to 
users.) Given that, what would be most useful to you? A flag to pass to `mach 
try` to get symbols uploaded for the builds for that push? A Treeherder action 
that would retroactively upload symbols for one or more builds from a try push? 
I'd love to hear from you!

Thanks,
-Ted

1. https://wiki.mozilla.org/ReleaseEngineering/TryServer#Getting_debug_symbols
2. https://bugzilla.mozilla.org/show_bug.cgi?id=1422096
3. https://bugzilla.mozilla.org/show_bug.cgi?id=1437577
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Chrome will start marking HTTP pages as "Not secure"

[Francis Djabri]

We haven't run any studies on security indicators as yet.


On Sun, Feb 11, 2018 at 5:55 PM, Bram Pitoyo  wrote:

> I’ve forwarded this conversation thread to our UX researcher and designer,
> Francis and Jacqueline. If we’ve run any studies, they’d be able to link us
> to a report.
>
> On 12 February 2018 at 11:58, Karl Dubost  wrote:
>
>> Johann,
>>
>> Le 10 févr. 2018 à 00:51, Johann Hofmann  a écrit :
>> > There's a valid concern around warning fatigue (plastering so many
>> sites with "Insecure" that users easily dismiss it) and we made those prefs
>> to be able to run user studies on it.
>>
>>
>> Did Mozilla run UX studies about it? If yes, links would be appreciated.
>>
>> Secure/Insecure intuitively seems for me a wrong metaphor. Or more
>> exactly a metaphor which has been carried away too long and has now lost
>> its meaning. Some HTTPS sites are/will not be secure. And some HTTP sites
>> will be more innocuous than some HTTPS sites.
>>
>>
>>
>> --
>> Karl Dubost, mozilla  Webcompat
>> http://www.la-grange.net/karl/moz
>>
>>
>>
>>
>>
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>
>


-- 

*Francis Djabri*
Firefox User Research
e: fdja...@mozilla.com
+1 (415) 696-2786 <(415)%20696-2786>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improved wpt-sync now running experimentally

[smaug]

On 02/09/2018 10:39 PM, James Graham wrote:

On 09/02/2018 19:59, Josh Bowman-Matthews wrote:

On 2/9/18 1:26 PM, James Graham wrote:

* One bug per PR we downstream, filed in a component determined by the files 
changed in the PR.


What does this mean exactly? What is the desired outcome of these bugs?


They're tracking the process and will be closed when the PR lands in central. They are used for notifying gecko developers about the incoming change, 
and in particular contain the information about tests that went from passing to failing, and other problems during the import.


I guess I don't understand the bugmail. Most of the time I don't see any 
information about something failing. Am I supposed to look at the commit?
Or are new failures in bugmail like
"
Ran 2 tests and 44 subtests
OK : 2
PASS   : 34
FAIL   : 10
"

Are those 10 failures new failures, or failures from the test total?


-Olli



They are not essential to the sync so if they end up not working well at 
keeping people informed we can revisit the approach.


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

[desktop] Bugs logged by Desktop Release QA in the last 8 days

[Bogdan Maris]

Hello,

Here's the list of new issues found and filed by the Desktop Release QA team 
last week.
Additional details on the team's priorities last week, as well as the plans for 
the current week are available at: https://goo.gl/6zX2gE

Bugs logged by Desktop Release QA in the last 8 days

Core: Keyboard: Navigation
*NEW - https://bugzil.la/1436015 - Full screen is dismissed when using spacebar 
key

Toolkit: Printing
*NEW - https://bugzil.la/1436066 - Incorrect appearance for RTL content inside 
Simplify Page

Firefox: Address Bar
*NEW - https://bugzil.la/1436294 - "chrome://..." URLs can't load when using 
"Paste & Go"

Core: DOM
*NEW - https://bugzil.la/1436334 - The fullscreen button is not fully 
functional on Bloomberg videos

Core: WebRTC: Audio/Video
*NEW - https://bugzil.la/1436963 - Multiple devicechange events are fired when 
plugging/unplugging a webcam with outdated driver

Toolkit: Printing
*NEW - https://bugzil.la/1437021 - [Ubuntu] Space inconsistency between 
characters inside Simplify Page

Core: General
*NEW - https://bugzil.la/1437027 - Crash in shutdownhang | 
libpthread-2.19.so@0xad0a

Firefox: Address Bar
*NEW - https://bugzil.la/1437043 - Tooltip flickers when Address Bar is opened 
with a clean profile

Core: DOM: Events
*NEW - https://bugzil.la/1437102 - [Pointer Events] Street View freezes when 
using stylus

This is available as a Bugzilla bug list as well: https://mzl.la/2o0oifn

Regards,
Bogdan (:bogdan_maris)
Desktop Release QA
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Treeherder New Login Flow

[Boris Zbarsky]

On 2/9/18 12:30 PM, ha...@mozilla.com wrote:

- Treeherder session will stay alive as long as access to the site happens once 
every 24 hours. 3 days session expiry is no longer in effect.


This seems to not be working at all.  I just carefully recorded the last 
time I logged in to treeherder: 8:39pm, on Feb 12, 2018, US/Eastern time.


It is now 9:27pm on the same day.  I just loaded treeherder.  It's 
showing me logged out.


The login didn't even last for 1 hour.

Login was done via LDAP.

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