Re: Improvement to build times through cleanup of C++ include dependencies
Due to the noisy nature of build times it might be too early to tell. Here's the telemetry dashboard for build: https://sql.telemetry.mozilla.org/dashboard/build?p_date=d_last_60_days (sorry - Mozilla employees only). Mike Conley wrote on 15/12/20 12:18 am: Thank you so much for investing time and effort into this area! Improvements to build times are always always welcome. I seem to recall we collect opt-in Telemetry on things like build times. If so, have we noticed any changes in those graphs? -Mike -- glob — engineering workflow manager — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Adding network level protection to bugzilla.mozilla.org
On 2020/10/19 our operations team will enable abuse protection measures in front of buzilla.mozilla.org (BMO). In the event that you are blocked by this system you will receive a 429 error. If you feel this is in error please reach out to the BMO and/or operations team via #bmo on Slack or the #bugzilla.mozilla.org channel on Matrix. The infrastructure being deployed is a centralised reputation system that is currently used to protect various other Firefox systems, including Firefox Accounts and Sync. More information can be found at https://github.com/mozilla-services/iprepd. -glob -- glob — engineering workflow manager — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Issue processing new revisions on Phabricator
Heads up that there's an issue with processing of new revisions on Phabricator; they will be stuck in a restricted state and cannot be reviewed while this issue exists. This issue should be fixed later today. This is tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1664972. Reach out to Joe Walker if you have an urgent need to land changes. -- glob — engineering workflow manager — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Delayed Bugzilla Emails
Due to an issue that occurred during the bugzilla.mozilla.org deployment yesterday (5th August), emails generated immediately following the deployment (2pm to 4pm US/Eastern) have been delayed. As the systems work through the backlog of approximately 12 thousand emails you may receive emails out of sequence. See https://bugzilla.mozilla.org/1657542 for more information. -- glob — engineering workflow manager — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Announcing MozillaBuild 3.3 Release
MozillaBuild 3.3 is a minor update to version 3.2 mostly focusing on updating a few of the bundled components to newer versions. https://ftp.mozilla.org/pub/mozilla/libraries/win32/MozillaBuildSetup-Latest.exe Important changes since version 3.2: * If Git is installed it will now be available to the MozillaBuild shell * Removed nodejs * Updated Python2 to version 2.7.16 and Python3 to version 3.7.4 * Updated emacs to 26.3 * Other updates to various included components. Full Release Notes: https://docs.google.com/document/d/1sIjCoqpRQqb-MbcZ7m6uLnlVSPh_CbQt2LfPYiqCfPc -glob -- glob — engineering workflow — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using MozPhab without Arcanist
It's available now - make sure you're running the latest version by running `moz-phab self-update`. -glob Henrik Skupin wrote on 23/10/19 11:49 pm: Piotr Zalewa wrote on 22.10.19 17:25: Since today MozPhab does not require Arcanist to submit patches in all supported VCS's. It's an optional and experimental feature. Add the `--no-arc` option to switch it on. Great to hear, but is there also an ETA when this mode will be available for users of Mercurial? When I use this option I get: NotImplementedError: Mercurial revisions can't be submitted without Arcanist Thanks -- glob — engineering workflow — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Help Wanted: Looking for policies related to Firefox development
The Engineering Workflow team is focused on improving the Firefox development processes. Many of the decisions are driven directly by established policies. Finding clearly documented policies has proven to be a challenge - policies are stored across multiple systems making them difficult find, are clearly out of date, or simply don’t exist. I’m working on creating a single catalogue which points to existing documentation (obsolete or not), and I’d like your help in finding documentation relating to Firefox development. This should help us identify and reduce: - “Mozilla Folklore” - where work is performed in a particular way however nothing is written down solidifying the practice. This is problematic for tooling as quite often there are slight variations between teams in how these practices are followed. One example that I’m trying to track down is “mozilla-central should be commit-level bisectable”. - Out of date documentation - a central catalogue simplifies locating documentation that needs to be updated or removed as our policies change. For example the Super Review Policy is still live, and contains a list of super-reviewers that appears to be 8+ years out of date. For now I’ve created a Google document at https://docs.google.com/document/d/1MUNJXL360V62FiWYVLr2b8Spt6I4jIOGjGkI7Agwxt4 as a collection point; please add your comments there or reply to this thread with pointers to documentation or to highlight “Mozilla Folklore” that you feel should be written down. The contents will be moved to a more suitable home once the initial gathering phase is completed. Thanks! -glob -- glob — engineering workflow — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Closure of #ateam irc channel
David Burns wrote on 22/1/19 5:16 pm: * #engworkflow - Engineering Work flow: Tooling for engineers phabricator, lando. #engworkflow isn't the best channel for most phabricator/lando questions; instead please ask questions in their respective channels: #phabricator and #lando. -- glob — engineering workflow — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Plan for Sunsetting MozReview
the redirect tool went live at the end of last week. Eric Shepherd (Sheppy) wrote on 10/9/18 7:44 pm: Yes, we have found that and have been using it but as you say, it loses some of the detail that has been historically helpful when writing documentation. We eagerly await the redirect tool. -- glob — engineering workflow — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Plan for Sunsetting MozReview
Dão Gottwald wrote on 5/9/18 1:37 am: This may have been discussed before since it's kind of an obvious question: https://groups.google.com/forum/#!msg/mozilla.dev.platform/V1vuWPeD_hc/d-hio96ZAwAJ https://groups.google.com/forum/#!msg/mozilla.dev.platform/Y8kInYxo8UU/e3Pi-_FpBgAJ https://groups.google.com/forum/#!msg/mozilla.dev.platform/Y8kInYxo8UU/tsF7UfxvBgAJ Was there a conscious decision not to post phabricator review comments to bugzilla? It's a somewhat significant change from how we've used bugzilla. I can see a potential upside of separating review comments from other planning and chatter. Then again, the line isn't always drawn easily. Plus, it makes it harder to migrate away from phabricator should we want that at some unknown point; that MozReview posted comments to bugzilla turns out to be quite valuable now. I'd prefer if review comments stayed in bugzilla with an option to hide them. dao 2018-07-26 20:37 GMT+02:00 Mark Côté <mailto:mc...@mozilla.com>>: To follow up on some previous threads, here is the plan for deprecating, archiving, and decommissioning MozReview. The MozReview shutdown deadline is approaching. Although enhanced commit-series support is still in progress (see update below), MozReview users should start familiarizing themselves with Phabricator now. We have a guide specifically for MozReview users to ease the transition (which will be updated when the commit-series work is finalized): https://moz-conduit.readthedocs.io/en/latest/mozreview-migration-guide.html <https://moz-conduit.readthedocs.io/en/latest/mozreview-migration-guide.html> From August 6 to August 20, use of MozReview will be restricted to updates to existing reviews. In other words, review cycles in progress will be given until August 20 to be completed, but no new commit series will be permitted. On August 20, we will remove public access to MozReview and archive patches. Every landed, in-progress, and abandoned patch will be downloaded from MozReview and stored in an S3 bucket. The “stub attachments” in Bugzilla that currently redirect to MozReview will be updated to link to the appropriate S3 bucket. Review flags and bug comments will be preserved. After archiving is complete and verified, the MozReview servers will be decommissioned. We will also be writing a simple redirection service to map specific MozReview reviews to associated BMO comments, review requests to associated bugs, and review-request diffs to the appropriate S3 buckets. This service will be up shortly after MozReview is decommissioned. We realize and apologize that this is a fairly short timeline; however, the current location of the MozReview servers is in the process of being shut down, and thus it is urgent that we decommission this service soon to allow an orderly exit. As for enhanced support for series of commits in Phabricator, the new command-line interface to submit, update, and apply series (bug 1471678) is currently in review. The first release will support Mercurial only, but git-cinnabar support will follow shortly (the code is designed with it in mind). Work on series support in Lando (bug 1457525) is progressing; we will be posting screenshots of the new UI shortly. It should be ready in 2-3 weeks. Please note that we eventually plan to decommission Splinter as well; however, we know we need some time to work out the kinks in Phabricator. Splinter will remain operational near-term, but we ask everybody to familiarize themselves with Phabricator and file bugs when things don't work. *Please do not wait for Splinter EOL to try Phabricator; we need your feedback before then in order to act on it.* Mark ___ firefox-dev mailing list firefox-...@mozilla.org <mailto:firefox-...@mozilla.org> https://mail.mozilla.org/listinfo/firefox-dev <https://mail.mozilla.org/listinfo/firefox-dev> ___ firefox-dev mailing list firefox-...@mozilla.org https://mail.mozilla.org/listinfo/firefox-dev -- glob — engineering workflow — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: pay attention when setting multiple reviewers in Phabricator
A better solution would be to have in-tree metadata files providing subscription rules for code review (e.g. a mapping of usernames to a list of patterns matching files). Module owners would be responsible for reviewing changes to these rules to ensure that automatic delegation happens to the correct people. I still don't believe this would work well in practice. It would work, but would have frequent problem cases and often require a lot of updating. at the end of the day tooling needs to ensure that reviewer has the authority to approve changes. i don't think the issues you've raised are show stoppers; it's certainly a system we will iterate on over time. keep in mind _how_ we work is also something we should be iterating on too. the current system is extremely coarse - everyone with scm-level-3 can approve any change tree-wide. there is a strong desire to make this finer grained. [snip] Some modules (i.e. DOM) already to have a hard requirement for peer review. That should be continued and should be enforced as it is now, and it sounds like Lando will (does?) support that. If another module wants to enforce it we can flip a bit in the list of peers and have it enforced. the enforcement you're referring to is controlled by a hardcoded list of peers inside a mercurial hook. this doesn't scale anywhere close to our needs, and all of the exact same concerns you raise with regards to in-tree ownership tracking applies (however it would be worse as it's imposed by a system separate from the review/landing tooling). -glob -- glob — engineering workflow — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: pay attention when setting multiple reviewers in Phabricator
Jean-Yves Avenard wrote on 3/7/18 6:23 am: On Mon, Jul 2, 2018 at 5:01 PM, Andreas Tolfsen <mailto:a...@sny.no>> wrote: Also sprach Marco Bonardo: > When asking for review to multiple reviewers, and all of them must accept > your revision, you must mark them as blocking reviews, either in the > Phabricator ui or appending "!" at the end of the reviewer name. Otherwise > it's first-come-first-serve. Note that is and also has been the case for mozreview. I don't ever recall mozreview having different kind of reviewer (blocker or non-blocker), if two people were added as reviewer, by default both had to review. it's correct that mozreview (and bugzilla) only have one type of reviewer. what multiple reviewers means in bugzilla/mozreview varies from team to team (all must review vs. any can review). it isn't correct that in mozreview two reviewers would both have to review. approval from _any_ reviewer would allow it to be landed with autoland: https://hg.mozilla.org/hgcustom/version-control-tools/file/tip/pylib/mozreview/mozreview/review_helpers.py#l34 i like that phabricator makes this distinction up-front. thanks mak for drawing attention to this difference/feature. -glob -- glob — engineering workflow — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: License of test data?
mhoye wrote: Does "just do it" imply that it's now OK to import that stuff without an analog of the previous r+ from Gerv? I'm putting together a licensing runbook with Legal's help, and the aim of that will be getting us to that point. As well, Glob is building some logic into Phabricator to automate a bunch of this stuff on ingest as well. to clarify the bits i'm working on aren't integrated with phabricator; it's a framework for standardising and automating how we vendor in code, and part of that is ensuring a license is specified and is one that we permit. it will exist as a new mach command. integration with build, review, and/or ci systems to automate license validation will be possible once this lands, but isn't part of the initial scope. -glob -- glob — engineering workflow — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent To Require Manifests For Vendored Code In mozilla-central
thanks to everyone who provided feedback for this proposal. looks like general consensus is to proceed with the plan. i've filed bug 1454867 to track the work. -glob glob wrote: The plan is to create a YAML file for each library containing metadata such as the homepage url, vendored version, bugzilla component, etc. See https://goo.gl/QZyz4xfor the full specification. this should be: https://goo.gl/QZyz4x for the full specification. -- glob — engineering workflow — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent To Require Manifests For Vendored Code In mozilla-central
Tom Tromey wrote: this should be: https://goo.gl/QZyz4x for the full specification. Some code in DevTools is vendored by dropping webpack bundles into the tree. The bundles are created by running a yarn command in the source repository; this also copies the bundle into an M-C tree. If these directories are going to have a moz.yaml, then either this process will have to be changed upstream, or the moz.yaml spec will have to change to account for this. for now we're focusing on places where we're vendoring in source. manifests for projects where we vendor in artefacts (eg. devtools, activity stream, screenshots, etc) will need to take a different approach, which will be addressed later (this is the primary reason for the manifest having a 'schema' field). -- glob — engineering workflow — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent To Require Manifests For Vendored Code In mozilla-central
James Graham wrote: So we now have moz.build that in addition to build instructions, contains metadata for mozilla-authored code (e.g. bugzilla components) and moz.yaml that will contain similar metadata but only for non-mozilla-authored code, as well as Cargo.toml that will contain (some of) that metadata but only for code written in Rust. As someone who ended up having to write code to update moz.build files programatically, the situation where we have similar metadata spread over three different kinds of files, one of them Turing complete, doesn't make me happy. Rust may be unsolvable, but it would be good if we didn't have two mozilla-specific formats for specifying metadata about source files. It would be especially good if updating this metadata didn't require pattern matching a Python AST. the build team recently decided to transition away from using moz.build files for declaring static metadata (such as bug components); see https://groups.google.com/forum/#!topic/mozilla.dev.builds/X5hbK6a4VQc -- glob — engineering workflow — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent To Require Manifests For Vendored Code In mozilla-central
Henri Sivonen wrote: This proposal makes sense to me when it comes to libraries that are not vendored from crates.io. However, this seems very heavyweight and only adds the Bugzilla metadata for crates.io crates. It seems to me that declaring the Bugzilla component isn't worth the trouble of having another metadata file in addition to Cargo.toml. i agree; excluding third-party/rust from this makes sense. sorry didn't explicitly call that out initially. Additonally, the examples suggest that this invents new ad hoc license identifiers. I suggest we not do that but instead use https://spdx.org/licenses/ and have a script to enforce that bogus values don't creep in. thanks; updated. -- glob — engineering workflow — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent To Require Manifests For Vendored Code In mozilla-central
thanks for the feedback martin, Please consider adding hg.mozilla.org to your list of things you will clone from. adding support to vendor from hg.m.o is a great suggestion, and shouldn't be problematic once the work has been proven with github. You don't permit the use of a tag for vendoring, is that intentional? to echo gps and mike's responses use of a sha to is preferred over tags. -- glob — engineering workflow — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent To Require Manifests For Vendored Code In mozilla-central
mozilla-central contains code vendored from external sources. Currently there is no standard way to document and update this code. In order to facilitate automation around auditing, vendoring, and linting we intend to require all vendored code to be annotated with an in-tree YAML file, and for the vendoring process to be standardised and automated. The plan is to create a YAML file for each library containing metadata such as the homepage url, vendored version, bugzilla component, etc. See https://goo.gl/QZyz4xfor the full specification. We will work with teams to add moz.yaml files where required, as well as adding the capability for push-button vendoring of new revisions. Please address comments to the dev-platform list. -- glob — engineering workflow — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: URL translation map Re: MXR permanently offline, please transition to DXR
Tim Guan-tin Chien wrote: A lot of code (including add-ons) out there also rely on MXR URL to fetch, for example, the public suffix list. https://github.com/search?q=https%3A%2F%2Fmxr.mozilla.org%2Fmozilla-central%2Fsource%2Fnetwerk%2Fdns%2Feffective_tld_names.dat&ref=searchresults&type=Code&utf8=%E2%9C%93 We would not be able to update these code effectively. (Yes, I know the right URL to hit should be https://publicsuffix.org/list/public_suffix_list.dat ) redirects are already in place for public_suffix_list.dat, as well as well as certdata.txt. https://mxr.mozilla.org/mozilla-central/source/netwerk/dns/effective_tld_names.dat?raw=1 http://mxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certdata.txt?raw=1 (via https://bugzilla.mozilla.org/show_bug.cgi?id=1281389) -glob -- byron jones :: glob.com.au <http://glob.com.au/> ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The integration/autoland repo
I am not using MozReview yet, because I lack answers for the 2 following questions: Is MozReview safe for hosting security patches yet? no. mozreview will prevent you from pushing a patch associated with a bug that isn't public. there's parts of the mozreview infrastructure that make that complicated right now; specifically the review repository you push to is public. it's on the roadmap but we want to address the core features and UX issues first. Also, I want to notice that, if persons who have access to security issues are using MozReview & autoland for all their patches which are not attached to a security issues, then this would highlight all the remaining patches as being involve in a fix for a security issue. Thus a simple filter on the committer name would be able to filter all security patches. (without the need to query bugzilla) this isn't accurate: when a patch is autolanded, the committer is set to the person who triggered autolanding, not a generic 'autoland' account. you cannot use the commiter name to filter our patches that were not autolanded. -glob ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MXR permanently offline, please transition to DXR
Philip Chee wrote: I wonder what is necessary to set up an instance of MXR (for comm-*) on our own server (or vps). I would guess PERL, hg, and a Linux VM. mxr was shutdown due to some very serious security issues; i strongly advise against standing up your own instance unless you first put a lot of time against securing it. you'd be better served by deploying an alternative source browser. -glob ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: status-firefox41: affected
this started happening via https://bugzilla.mozilla.org/show_bug.cgi?id=972040 please file a bug and we'll apply per-product filtering -- currently it'll be set on any product that has that flag. (i'm not sure why seamonkey has that flag visible on its bugs) -glob Philip Chee wrote: On 31/05/2015 16:02, Sylvestre Ledru wrote: I don't know about this specific issue but I asked to Ryan a few months back that the status firefox would be automatically marked as "fixed" for the current nightly. I guess this is related to this. Yahbutt the flag doesn't get changed to fixed when I close said SeaMonkey bug. The "affected" status flags being automatically set started a few weeks ago. It's hard to imagine how a bug about (say) the toilets in Mountain View backing up could affect firefox Phil ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
