Renaming nsAString_internal to nsAString

[David Major]

TL;DR this will change crash signatures and possibly other tool output;
talk to me if this adversely affects you.

Now that bug 1332639 has removed the external string API, we no longer need
to differentiate between internal and external strings.

Currently we #define nsAString to nsAString_internal, so even though we
write nsAString in the source, the binary thinks the name is
nsAString_internal. Same for nsACString.

In bug 1346078 I plan to remove the #defines so that we just have
nsA(C)String in the binary.

If you have tools outside the tree that depend on the _internal names,
please let me know. (I'm already aware of the servo bindings and will
address those)

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

Intent to build (but not enable) WebRender by default on some Nightly platforms

[Kartikaya Gupta]

(Cross-posted to dev-platform and dev-tech-gfx, please reply to dev-platform)

In the near future I'm planning to make a change so that WebRender
will be built (but not enabled) by default in most Nightly/local
builds [1]. This will allow anybody running a stock nightly to turn on
The QuantumRender Experience™ by flipping a pref [2] and restarting
the browser [3].

Because this change will build more rust code into libxul,
compilation/linking time may be negatively impacted. Developers will
still be able to explicitly disable building webrender by putting
`ac_add_options --disable-webrender` in their mozconfig.

Furthermore, explicitly putting `ac_add_options --enable-webrender`
into your mozconfig will enable the pref for you by default, so that
if you have been doing builds with this flag already and expecting QR
to be on by default, it will continue to do so.

Patches are in bug 1342450 and dependencies if you want to follow
along. If you run into problems with this, please file a bug and cc
me, or reply to this email.

Cheers,
kats

[1] Not yet on Android, or OS X automation builds on Buildbot
[2] The pref is gfx.webrender.enabled
[3] There are more conditions in play than just the pref, see
gfxPlatform::InitWebRenderConfig().
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Please write good commit messages before asking for code review

[smaug]

On 03/10/2017 12:43 AM, Ben Kelly wrote:

On Thu, Mar 9, 2017 at 5:35 PM, Mike Hommey  wrote:


On Thu, Mar 09, 2017 at 02:46:53PM -0500, Ehsan Akhgari wrote:

I review a large number of patches on a typical day, and usually I have

to

spend a fair amount of time to just understand what the patch is doing.

As

the patch author, you can do a lot to help make this easier by *writing
better commit messages*.  Starting now, I'm going to try out a new

practice

for a while: I'm going to first review the commit message of all patches,
and if I can't understand what the patch does by reading the commit

message

before reading any of the code, I'll r- and ask for another version of

the

patch.


Sometimes, the commit message does explain what it does in a sufficient
manner, but finding out why requires reading the bug, assuming it's
written there. I think this information should also be in the commit
message.



(Just continuing the thread here.)

Personally I prefer looking at the bug for the full context and single
point of truth.  Also, security bugs typically can't have extensive commit
messages and moving a lot of context to commit messages might paint a
target on security patches.



Exactly. In practice I tend to just read the first line of a commit message and 
the most important part there is the bug number.
I've never been a fan of overlong commit messages.
MozReview makes this a bit different since it decouples bugs and changes, so 
there seeing more explanation in the commit message is more useful.

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

Re: The future of commit access policy for core Firefox

[zbraniecki]

On Monday, March 13, 2017 at 7:45:44 AM UTC-7, Byron Jones wrote:
> David Burns wrote:
> > We should try mitigate the security problem and fix our nit problem 
> > instead of bashing that we can't handle re-reviews because of nits.
> one way tooling could help here is to allow the reviewer to make minor 
> changes to the patch before it lands.
> ie.  "r+, fix typo in comment before landing" would become "r+, i fixed 
> the comment typo"

I don't think it's realistic to expect already-overloaded reviewers to do even 
more.

In my experience, reviewer's time is worth ~4 times more than patch author's 
time.
That's a completely arbitrary number, but represents how in my experience the 
load balance work.

So, I'd actually say we should do everything possible to *minimize* the amount 
of time required from the reviewer, rather than increasing it.

And I also don't think that increasing the number of reviewers would fix it. 
Reviewer by nature is often a senior engineer trying to balance out writing 
patches that very few people can, and review patches that less experienced 
engineers wrote.

Their time is insanely valuable because neither of those tasks can be easily 
done by the person requesting the review.

Of course there are exceptions like peer-reviews and rubber-stamping of a 
patch, but in general, I'd like us to think about shifting the burden onto 
automation / patch author to do as much work as possible before the reviewer 
commits their time.
And once their done, once again we should imho limit the time we expect from 
the reviewer for any follow-up reviews.

For that reason, the lack of interdiff in rebase scenario in MR is a major 
hassle in my experience. And the idea that the reviewer has to re-review 
multiple times or edit the patch themselves, as a step in the wrong direction.

Also, the idea that "anyone can re-review the patch" is very shaky. It would 
not work in the most crucial and delicate areas where the number of people 
familiar with the area is just low. Say, accessibility, graphics, 
internationalization, security etc.

In those lines, there's often a single person in the organization who can 
comfortably review the patch, and if they're in a different timezone, then 
asking a random reviewer on IRC for a review on nits is an illusion if the nits 
are anything beyond "update the comment".

On top of that, the idea also taps into the concern I raised above. Cognitive 
load required for a reviewer to step into a bug, skim through all comments, 
patch history and latest review with request for nits to understand if the nits 
represent the original reviewer request is also non trivial.

The way it's presented in this thread feels like a utopian vision where anyone 
can just take a quick glance and stamp an r+, but in reality it'll either add 
significantly to the load of already overloaded group in our project, or become 
an illusion of security with people just accepting everything from people they 
know.

I'm actually concerned that in the era where most projects go in the direction 
of streamlining the development and reducing the bureaucracy as much as 
possible (post-landing reviews, peer-reviews etc.), we're talking about adding 
another hoop to jump through.

I'm all for increased security (2FA etc.), but unless there's an unspoken set 
of cases where security of our project has been compromised by a change in the 
patch that was added after r+, I'd like to question if we're really at the 
point where we need such tradeoff.

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

Re: Startup JS debugging (sometimes) possible via Browser Toolbox

[J. Ryan Stinnett]

On Mon, Mar 13, 2017 at 2:04 PM, Jared Wein  wrote:

> Yes, we support watches in the new debugger UI now. The new debugger UI is
> used by default in the Browser Content Toolbox, and it is pretty nice and
> shiny.


New debugger UI is on for Browser Content Toolbox, but at the moment, it's
still off for Browser Toolbox.

It was disabled for Browser Toolbox ~6 months ago in bug 1300820, but those
issues appear to have been resolved since then.

I filed bug 1346902 to enable it again for Browser Toolbox.

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

Re: Startup JS debugging (sometimes) possible via Browser Toolbox

[Jared Wein]

Yes, we support watches in the new debugger UI now. The new debugger UI is
used by default in the Browser Content Toolbox, and it is pretty nice and
shiny.

Cheers,
Jared

On Mon, Mar 13, 2017 at 12:50 PM, Gijs Kruitbosch 
wrote:

> On 13/03/2017 16:48, J. Ryan Stinnett wrote:
>
>
> On Thu, Mar 9, 2017 at 2:18 AM, Panos Astithas  wrote:
>
>> You almost completely resolved the 4-year-old bug 814298, yay! I now
>> wonder if this makes it easier to improve mochitest debugging per bug
>> 929535.
>
>
> Thanks for the pointers to these bugs.
>
> Bug 814298 stills needs breakpoint persistence to be fully resolved, but
> this will hopefully appear soon in the new debugger UI.
>
> The new debugger UI isn't enabled for chrome debugging, though. What's
> blocking that? (And do we support watches in the new debugger UI yet? :-) )
>
> ~Gijs
>
> ___
> 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: The future of commit access policy for core Firefox

[Ehsan Akhgari]

On 2017-03-12 4:53 PM, smaug wrote:
> On 03/12/2017 10:40 PM, Ehsan Akhgari wrote:
>> On 2017-03-11 9:23 AM, smaug via governance wrote:
>>> On 03/11/2017 08:23 AM, Nicholas Nethercote wrote:
 On Sat, Mar 11, 2017 at 2:23 PM, smaug via governance <
 governa...@lists.mozilla.org> wrote:
>
> I'd be ok to do a quick r+ if interdiff was working well.

 Depending on the relative timezones of the reviewer and reviewee, that
 could delay landing by 24 hours or even a whole weekend.

>>> The final r+, if it is just cosmetic changes wouldn't need to be done by
>>> the same reviewer.
>>
>> OK, but what is the exact time zone efficient way to ensure that no huge
>> amount of delay is added for the turn around of this final review round?
>>
>> Let's be realistic.  In practice, adding one extra person in the process
>> of landing of the patches that currently land with r+-with-nits *will*
>> slow them down.  And we should expect that it will slow them down by
>> factors such as time zones, people missing bugmail, etc,
> 
> Why we need to expect that? In my mind the process would be closer to
> "I want to land this patch, asking ok-to-land on irc." And then someone
> who has the rights to say ok to that would
> mark the patch after seeing that the interdiff doesn't add anything
> inherently bad.
> (well working interdiff and tooling in general is rather critical)

Depending on the timezone, finding people on IRC may be challenging.
For example, many of our colleagues in Taipei may find this kind of IRC
reviews difficult if the people who need to look at the change are on
the other side of the planet.

>> all of the
>> reasons why currently one review can end up taking a week,
> I see this being _very_ different to normal reviews.
> 
> I do understand that people don't want extra process. Overhead is always
> overhead.
> But the overhead here might not be as bad as feared.
> 
>> it may end up
>> being that final round of review after this proposed change.
>>
>> And I still don't understand what the proposal means with rebases in
>> practice.  What if, after automation tries to land your change after you
>> got your final r+ the final rebase fails and you need to do a manual
>> rebase?  Do you need to get another r+?  What happens if you're touching
>> one of our giant popular headers and someone else manages to land a
>> conflict while your reviewer gets back to you?
>>
>>> Perhaps we shouldn't even call the last step a review. It would be
>>> "ok-to-land".
>>> r+ without asking any changes would implicitly contain that
>>> "ok-to-land".
>>> (if rebasing causes some changes, that would then need explicit
>>> "ok-to-land")
>>
>> Are you suggesting a change to the nature of the review process for the
>> last step with the rename?
> 
> The last step here would be quite different to normal reviews. It is
> just a rather quick glance-over that no
> obviously evil code is about to land. (as I said, well working interdiff
> is absolutely critical to make this working)

OK, this distinction is key.  To me this seems adding process for the
sake of adding process.  Is this really going to be all that much better
at preventing vulnerabilities from sneaking in than what we have today?

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

Re: Startup JS debugging (sometimes) possible via Browser Toolbox

[Gijs Kruitbosch]

On 13/03/2017 16:48, J. Ryan Stinnett wrote:


On Thu, Mar 9, 2017 at 2:18 AM, Panos Astithas > wrote:


You almost completely resolved the 4-year-old bug 814298, yay! I
now wonder if this makes it easier to improve mochitest debugging
per bug 929535. 



Thanks for the pointers to these bugs.

Bug 814298 stills needs breakpoint persistence to be fully resolved, 
but this will hopefully appear soon in the new debugger UI.
The new debugger UI isn't enabled for chrome debugging, though. What's 
blocking that? (And do we support watches in the new debugger UI yet? :-) )


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

Re: Startup JS debugging (sometimes) possible via Browser Toolbox

[J. Ryan Stinnett]

On Thu, Mar 9, 2017 at 2:18 AM, Panos Astithas  wrote:

> You almost completely resolved the 4-year-old bug 814298, yay! I now
> wonder if this makes it easier to improve mochitest debugging per bug
> 929535.


Thanks for the pointers to these bugs.

Bug 814298 stills needs breakpoint persistence to be fully resolved, but
this will hopefully appear soon in the new debugger UI.

For mochitest debugging (bug 929535), this new flag does seem to be
sufficient to allow the tests to run automatically while still debugging,
so I've just landed a fix there.

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

Re: Tracking bug for removals after XPCOM extensions are no more?

[Kris Maglione]

On Mon, Mar 13, 2017 at 08:36:05AM -0700, Steve Fink wrote:
For the record, there's some nonobvious stuff I can remove from the 
rooting hazard analysis due to this -- currently, it conservatively 
assumes that just about any nsISupports subclass's method could be 
implemented in a binary extension, and thus could trigger a garbage 
collection that moves all of your GC-controlled pointers while 
laughing evilly at your now-bogus stack pointers to the old locations.


Are we talking about the removal of binary extension components, or 
about removal of support for XUL/XPConnect extensions? Binary components 
should already be gone. There are a lot of other things we should be 
able to remove after we remove XUL extensions.

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

Re: Tracking bug for removals after XPCOM extensions are no more?

[Steve Fink]

On 03/13/2017 06:17 AM, Nathan Froyd wrote:

We do not.  Bug 1299187 is related to such work, but that bug only
covers unexporting symbols that 3rd party software would access.  bz
has filed a few bugs for removing nsIDOM* methods that only existed
due to 3rd party compat concerns, but I don't think there's been
systematic evaluation of what's just dead weight now.


For the record, there's some nonobvious stuff I can remove from the 
rooting hazard analysis due to this -- currently, it conservatively 
assumes that just about any nsISupports subclass's method could be 
implemented in a binary extension, and thus could trigger a garbage 
collection that moves all of your GC-controlled pointers while laughing 
evilly at your now-bogus stack pointers to the old locations.


There's a whitelist of "safe" things that we assume will never be 
overridden. But now I can remove everything that treats nsISupports 
specially.


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

Re: The future of commit access policy for core Firefox

[James Graham]

On 13/03/17 14:45, Byron Jones wrote:

David Burns wrote:

We should try mitigate the security problem and fix our nit problem
instead of bashing that we can't handle re-reviews because of nits.

one way tooling could help here is to allow the reviewer to make minor
changes to the patch before it lands.
ie.  "r+, fix typo in comment before landing" would become "r+, i fixed
the comment typo"



Assuming you mean "and land without further review", I don't see how 
this has different security properties from r+-with-nits in the — 
reasonably common — case that the patch author is at least as trusted as 
the reviewer (e.g. both L3 today).


I do think that tooling to support multiple authors collaborating on a 
single branch is a good thing independent of the changes discussed in 
this thread.

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

Re: The future of commit access policy for core Firefox

[Byron Jones]

David Burns wrote:
We should try mitigate the security problem and fix our nit problem 
instead of bashing that we can't handle re-reviews because of nits.
one way tooling could help here is to allow the reviewer to make minor 
changes to the patch before it lands.
ie.  "r+, fix typo in comment before landing" would become "r+, i fixed 
the comment typo"


--
glob — engineering productivity — moz://a

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

Re: The future of commit access policy for core Firefox

[David Burns]

As the manager of the sheriffs, I am in favour of this proposal.

The reasons why are as follow (and to note there are only 3 paid sheriffs
to try cover the world):

* A number of r+ with nits land up in the sheriffs queue for
checkin-needed. This then puts the onus on the sheriffs, not the reviewer
that the right thing has been done. The sheriffs do no have the context
knowledge of the patch, never mind the knowledge of the system being
changed.

* The throughput of patches into the trees is only going to increase. If
there are failures, and the sheriffs need to back out, this can be a long
process depending on the failure leading to pile ups of broken patches.

A number of people have complained that using autoland doesn't allow us to
fail forward on patches. While that is true, there is the ability to do
T-shaped try pushes to make sure that you at least compile on all
platforms. This can easily done from Mozreview (Note: I am not suggesting
we move to mozreview).

Regarding burden on reviewers, the comments in this thread just highlight
how broken our current process is by having to flag individual people for
reviews. This leads to the a handful of people doing 50%+ of reviews on the
code. We, at least visibly, don't do enough to encourage new committers
that would lighten the load to allow the re-review if there are nits. Also,
we need to do work to automate the removal of nits to limit the amount of
re-reviews that reviewer can do.

We should try mitigate the security problem and fix our nit problem instead
of bashing that we can't handle re-reviews because of nits.

David

On 9 March 2017 at 21:53, Mike Connor  wrote:

> (please direct followups to dev-planning, cross-posting to governance,
> firefox-dev, dev-platform)
>
>
> Nearly 19 years after the creation of the Mozilla Project, commit access
> remains essentially the same as it has always been.  We've evolved the
> vouching process a number of times, CVS has long since been replaced by
> Mercurial & others, and we've taken some positive steps in terms of
> securing the commit process.  And yet we've never touched the core idea of
> granting developers direct commit access to our most important
> repositories.  After a large number of discussions since taking ownership
> over commit policy, I believe it is time for Mozilla to change that
> practice.
>
> Before I get into the meat of the current proposal, I would like to
> outline a set of key goals for any change we make.  These goals have been
> informed by a set of stakeholders from across the project including the
> engineering, security, release and QA teams.  It's inevitable that any
> significant change will disrupt longstanding workflows.  As a result, it is
> critical that we are all aligned on the goals of the change.
>
>
> I've identified the following goals as critical for a responsible commit
> access policy:
>
>
>- Compromising a single individual's credentials must not be
>sufficient to land malicious code into our products.
>- Two-factor auth must be a requirement for all users approving or
>pushing a change.
>- The change that gets pushed must be the same change that was
>approved.
>- Broken commits must be rejected automatically as a part of the
>commit process.
>
>
> In order to achieve these goals, I propose that we commit to making the
> following changes to all Firefox product repositories:
>
>
>- Direct commit access to repositories will be strictly limited to
>sheriffs and a subset of release engineering.
>   - Any direct commits by these individuals will be limited to fixing
>   bustage that automation misses and handling branch merges.
>- All other changes will go through an autoland-based workflow.
>   - Developers commit to a staging repository, with scripting that
>   connects the changeset to a Bugzilla attachment, and integrates with 
> review
>   flags.
>   - Reviewers and any other approvers interact with the changeset as
>   today (including ReviewBoard if preferred), with Bugzilla flags as the
>   canonical source of truth.
>   - Upon approval, the changeset will be pushed into autoland.
>   - If the push is successful, the change is merged to
>   mozilla-central, and the bug updated.
>
> I know this is a major change in practice from how we currently operate,
> and my ask is that we work together to understand the impact and concerns.
> If you find yourself disagreeing with the goals, let's have that discussion
> instead of arguing about the solution.  If you agree with the goals, but
> not the solution, I'd love to hear alternative ideas for how we can achieve
> the outcomes outlined above.
>
> -- Mike
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list

[Firefox Desktop] Issues found: March 6th to March 10th

[Cornel Ionce]

Hi everyone,


Here's the list of new issues found and filed by the Desktop Release QA 
Team last week, *March 6 - March 10* (week 10).


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*
none

*BETA CHANNEL*

ID  Summary Product Component   Is a regression 
Assigned to
1345473  	Changing tab order using Compact 
themes cause an overlap

Firefox
Tabbed Browser
	YES 
 
	J. Ryan Stinnett 



*AURORA CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1345877 
Dotted square appears above the in focused video's seek bar in Linkedin
Core
Audio/Video: Playback
NO  NOBODY


*NIGHTLY CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1344780 
	Missing menubar area when changing the width of Fx between two screens 
(HiDPi & lowdpi)

Core
Widget: Win32
	YES 
 
	NOBODY

1345383 
	Download Panel dropdown menu is not dismissed after opening other icon 
dropdowns

Firefox
Downloads Panel
NO  NOBODY
1345812 
	Hover feedback effect size of tools from navbar changes once PixelPerPx 
value changes

Firefox
Theme
TBD NOBODY
1345864 
	[Linux] Graphical issues in Panel Menu when using different values for 
devPixelsPerPx

Firefox
Menus
NO  NOBODY
1345891 
threejs CSS3D panorama has graphical issues
Core
Graphics
TBD NOBODY
1346221 
	The user is able to select another username from the drop down list 
only after manually clearing the username field

Toolkit
Password Manager
NO  NOBODY
1346380
 	The Chart pie from Statistics view is not 
loading on BBC or CNN

Firefox
Developer Tools: Netmonitor
	YES 
 
	NOBODY


*
ESR CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1344644
 	If Edge is running, Firefox freezes when 
starting the import Wizard

Firefox  Migration
	YES 
 
	Gijs 




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: The future of commit access policy for core Firefox

[smaug]

On 03/10/2017 12:59 AM, Bobby Holley wrote:

At a high level, I think the goals here are good.

However, the tooling here needs to be top-notch for this to work, and the
standard approach of flipping on an MVP and dealing with the rest in
followup bugs isn't going to be acceptable for something so critical to our
productivity as landing code. The only reason more developers aren't
complaining about the MozReview+autoland workflow right now is that it's
optional.

The busiest and most-productive developers (ehsan, bz, dbaron, etc) tend
not to pay attention to new workflows because they have too much else on
their plate. The onus needs to be on the team deploying this to have the
highest-volume committers using the new system happily and voluntarily
before it becomes mandatory. That probably means that the team should not
have any deadline-oriented incentives to ship it before it's ready.

Also, getting rid of "r+ with comments" is a non-starter.


FWIW, with my reviewer hat on, I think that is not true, _assuming_ there is a 
reliable interdiff for patches.
And not only MozReview patches but for all the patches. (and MozReview 
interdiff isn't reliable, it has dataloss issues so it
doesn't really count there.).
I'd be ok to do a quick r+ if interdiff was working well.



-Olli



bholley


On Thu, Mar 9, 2017 at 1:53 PM, Mike Connor  wrote:


(please direct followups to dev-planning, cross-posting to governance,
firefox-dev, dev-platform)


Nearly 19 years after the creation of the Mozilla Project, commit access
remains essentially the same as it has always been.  We've evolved the
vouching process a number of times, CVS has long since been replaced by
Mercurial & others, and we've taken some positive steps in terms of
securing the commit process.  And yet we've never touched the core idea of
granting developers direct commit access to our most important
repositories.  After a large number of discussions since taking ownership
over commit policy, I believe it is time for Mozilla to change that
practice.

Before I get into the meat of the current proposal, I would like to outline
a set of key goals for any change we make.  These goals have been informed
by a set of stakeholders from across the project including the engineering,
security, release and QA teams.  It's inevitable that any significant
change will disrupt longstanding workflows.  As a result, it is critical
that we are all aligned on the goals of the change.


I've identified the following goals as critical for a responsible commit
access policy:


- Compromising a single individual's credentials must not be sufficient
to land malicious code into our products.
- Two-factor auth must be a requirement for all users approving or
pushing a change.
- The change that gets pushed must be the same change that was approved.
- Broken commits must be rejected automatically as a part of the commit
process.


In order to achieve these goals, I propose that we commit to making the
following changes to all Firefox product repositories:


- Direct commit access to repositories will be strictly limited to
sheriffs and a subset of release engineering.
   - Any direct commits by these individuals will be limited to fixing
   bustage that automation misses and handling branch merges.
- All other changes will go through an autoland-based workflow.
   - Developers commit to a staging repository, with scripting that
   connects the changeset to a Bugzilla attachment, and integrates
with review
   flags.
   - Reviewers and any other approvers interact with the changeset as
   today (including ReviewBoard if preferred), with Bugzilla flags as
the
   canonical source of truth.
   - Upon approval, the changeset will be pushed into autoland.
   - If the push is successful, the change is merged to mozilla-central,
   and the bug updated.

I know this is a major change in practice from how we currently operate,
and my ask is that we work together to understand the impact and concerns.
If you find yourself disagreeing with the goals, let's have that discussion
instead of arguing about the solution.  If you agree with the goals, but
not the solution, I'd love to hear alternative ideas for how we can achieve
the outcomes outlined above.

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



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

Re: Tracking bug for removals after XPCOM extensions are no more?

[Nathan Froyd]

We do not.  Bug 1299187 is related to such work, but that bug only
covers unexporting symbols that 3rd party software would access.  bz
has filed a few bugs for removing nsIDOM* methods that only existed
due to 3rd party compat concerns, but I don't think there's been
systematic evaluation of what's just dead weight now.
-Nathan

On Fri, Mar 10, 2017 at 6:40 AM, Henri Sivonen  wrote:
> Do we have a tracking bug for all the stuff that we can and should
> remove once we no longer support XPCOM extensions?
>
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
> ___
> 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: The future of commit access policy for core Firefox

[Eric Rescorla]

On Mon, Mar 13, 2017 at 12:22 AM, Frederik Braun  wrote:

> On 12.03.2017 04:08, Cameron Kaiser wrote:
> > On 3/10/17 4:38 AM, Masatoshi Kimura wrote:
> >> On 2017/03/10 6:53, Mike Connor wrote:
> >>> - Two-factor auth must be a requirement for all users approving or
> >>> pushing a change.
> >>
> >> I have no mobile devices. How can I use 2FA?
> >>
> >> Previously I was suggested to buy a new PC and SSD only to shorten the
> >> build time. Now do I have to buy a smartphone only to contribute
> >> Mozilla? What's the next?
> >
> > I actually use a Perl script to do HOTP. And there are things like
> > Firekey. No mobile device necessary.
>
> Doesn't that defeat the point of a second factor?
>

Not entirely, no, because it is not replayable.

-Ekr


>
> >
> > Cameron Kaiser
> > tier-3-2-1-contact!
> > ___
> > 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Planned tree closure Tue 2017-03-14 08:30 UTC

[James Graham]

We will be running a migration on the Treeherder database which will 
require pausing job ingestion at 08:30 UTC tomorrow (Tuesday). This is 
expected to take around 90 minutes, and trees will be closed for the 
duration.


Thank  you for your patience.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The future of commit access policy for core Firefox

[Frederik Braun]

On 12.03.2017 04:08, Cameron Kaiser wrote:
> On 3/10/17 4:38 AM, Masatoshi Kimura wrote:
>> On 2017/03/10 6:53, Mike Connor wrote:
>>> - Two-factor auth must be a requirement for all users approving or
>>> pushing a change.
>>
>> I have no mobile devices. How can I use 2FA?
>>
>> Previously I was suggested to buy a new PC and SSD only to shorten the
>> build time. Now do I have to buy a smartphone only to contribute
>> Mozilla? What's the next?
> 
> I actually use a Perl script to do HOTP. And there are things like
> Firekey. No mobile device necessary.

Doesn't that defeat the point of a second factor?

> 
> Cameron Kaiser
> tier-3-2-1-contact!
> ___
> 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