The NSS team still uplifts from https://hg.mozilla.org/projects/nss/ into m-c <https://github.com/mozilla/nss-tools/blob/master/nss-uplift-unified.sh> a few times per week (or as needed) using inbound <https://hg.mozilla.org/integration/mozilla-inbound/rev/eee8ce2afe60f5fcd62c7aaaf4122cdce02d4544>. That's mostly a function of those uplifts being r=me, as they already were reviewed in the NSS repo.
There's nothing technically stopping me from using Phabricator for those uplifts; they'd just need an additional (perfunctory) review sign-off. On Fri, Feb 8, 2019 at 7:08 AM Andreas Tolfsen <a...@sny.no> wrote: > Also sprach Kim Moir: > > > Requiring Phabricator for code reviews will allow us to improve > > code quality by running linters and static analysis tools automatically > > on patches. It will also allow us to simplify and standardize our > > engineering workflow by reducing the number of request queues that > > developers are expected to monitor. > > Are there any firm plans to also reduce the number of integration > queues? > > With this change, which products/teams are still relying on r+/r- > and inbound? > > Whilst I don’t have first hand experience, Phabricator has been > known to struggle with large patches, such as the result of upgrading > cargo dependencies under third_party/rust. Was a bug ever filed > on this? > > _______________________________________________ > 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
