Also search Emilio Cobos Álvarez:
> On 11/2/19 12:53 PM, Andreas Tolfsen wrote:
>> Documentation changes have historically been well served by a “wiki
>> editing”/micro adjustments approach. I wonder if there is anything
>> we can do with Phabricator to ease review requirements for documentation
Just a note to let everyone know the hg.mozilla.org permissions change was
implemented this morning. Thanks to everyone for the work that allowed us
to make our code repositories more secure.
Kim
On Fri, Nov 1, 2019 at 4:39 PM Kim Moir wrote:
> The Engineering Workflow team enabled a hook in J
On Saturday, November 2, 2019 at 12:03:25 AM UTC+1, somb...@gmail.com wrote:
> For mozilla-beta, mozilla-release, and esr... does lando know how to
> land to these, or is it the case that landings on these branches are
> done based on the approval flags by people other than the patch author?
I'm
On Mon, Nov 4, 2019 at 8:36 AM David Teller wrote:
> For what it's worth, when I last tried, I couldn't even `moz-phab
> submit` a self-reviewed patch. I had to arbitrarily pick another
> reviewer for a patch that was not meant for landing (it was a
> demonstration of a reproducible bug in phabri
For what it's worth, when I last tried, I couldn't even `moz-phab
submit` a self-reviewed patch. I had to arbitrarily pick another
reviewer for a patch that was not meant for landing (it was a
demonstration of a reproducible bug in phabricator, but that's another
story).
Cheers,
Yoric
On 03/11/2
On 11/2/19 12:53 PM, Andreas Tolfsen wrote:
Documentation changes have historically been well served by a “wiki
editing”/micro adjustments approach. I wonder if there is anything
we can do with Phabricator to ease review requirements for documentation
changes from peers?
I think you can land p
Also sprach Kim Moir:
> On Nov 14, 2019, we intend to change the permissions associated
> with Level 3 access to revoke direct push access to hg.mozilla.org
> on mozilla-inbound,
Several modules have a policy that changes to documentation, e.g.
for https://firefox-source-docs.mozilla.org/, can be
On 11/1/19 4:03 PM, Andrew Sutherland wrote:
On 11/1/19 4:39 PM, Kim Moir wrote:
On Nov 14, 2019, we intend to change the permissions associated with
Level
3 access to revoke direct push access to hg.mozilla.org on
mozilla-inbound,
mozilla-central, mozilla-beta, mozilla-release and esr repos.
On 11/1/19 4:39 PM, Kim Moir wrote:
On Nov 14, 2019, we intend to change the permissions associated with Level
3 access to revoke direct push access to hg.mozilla.org on mozilla-inbound,
mozilla-central, mozilla-beta, mozilla-release and esr repos.
For mozilla-beta, mozilla-release, and esr...
Officially decommissioning m-i will take place after we change the
permissions. It will remain a read-only repo for historical purposes. No I
don't see a need to run things in CI on m-i beyond that date.
deprecate mozilla-inbound after Lando is used for most mozilla-central
landing
https://bugzill
Very nice!
Does this mean mozilla-inbound is effectively decommissioned at this point?
Are there any circumstances it will need to run things in CI beyond
November 14th?
-Andrew
On Fri, Nov 1, 2019 at 4:39 PM Kim Moir wrote:
> The Engineering Workflow team enabled a hook in July which asked p
\o/
I think this is a really good thing. The smaller the surface for people to
land code without sufficient guarantees that it went through a review
mechanism, the better.
Thanks to you and your team for their work!
-Mike
On Fri, 1 Nov 2019 at 16:39, Kim Moir wrote:
> The Engineering Workflow
The Engineering Workflow team enabled a hook in July which asked people to
provide a reason for directly pushing to hg.mozilla.org. Since it was
enabled, we have seen the number of direct pushes decrease to a few per
week.
Enabling developers to use standard tools to land reviewed code through a
13 matches
Mail list logo
