Community

Mailing List and Chat Channel

We have an LLVM-sponsored flang-dev mailing list for Flang:

https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev

It is used for both LLVM Flang and the "classic" Flang compiler hosted in this repository. To identify emails related to Classic Flang, use the prefix [ClassicFlang] in the email subjects.

We have a flang-compiler channel on Slack. Here is the invitation link:

https://join.slack.com/t/flang-compiler/shared_invite/zt-2pcn51lh-VrRQL_YUOkxA_1CEfMGQhw

Reporting Bugs

Please submit bugs and requests for enhancements via the Issues link.

Contributing Code

The Flang project is licensed under the "Apache 2.0 with LLVM Exception" license. Details of the LLVM licensing and structure of the new file headers can be found here:

• https://llvm.org/foundation/relicensing/

Files submitted to Flang should include the standard LLVM header, similar to this:

//===-- file/name - File description ----------------------------*- C++ -*-===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//

Conformance to the LLVM Coding Standards is encouraged, but not mandatory. In particular, the style of function declarations is kept consistent with historical code. Users of clang-format may try formatting new patches using the following options:

BasedOnStyle: LLVM
AlwaysBreakAfterDefinitionReturnType: TopLevel
BreakBeforeBraces: WebKit
SortIncludes: false

Pull Request Process

The goal of the Flang Community Pull Request Process is to ensure that only well-tested patches are incorporated into the master branch. Most Fortran tests, benchmarks, and applications are proprietary, and therefore are not part of the public Flang test suite, but these are the tests that need to be run in order to continue to maintain the quality of flang.

To that end, a group of individuals and organizations have volunteered to test and discuss pull requests. The process allows just two assenting votes before a gatekeeper is allowed to merge a pull request into the master branch.

Current volunteers (reviewers) and their commitments:

• Shivarama Rao, AMD, for X86_64 testing
• Kiran Chandramohan, Pawel Osmialowski, Arm, for AArch64 testing
• Bryan Chan, Huawei, for AArch64 testing
• Xoviat, Adam Kallai, Isuru Fernando for Windows testing

If you would like to volunteer to review pull requests, please submit your request to the flang-dev email list.

Current gatekeepers:

• Mark Leair, David Parks and Steve Scalpone, NVIDIA
• Kiran Chandramohan, Pawel Osmialowski and Rich Barton, Arm
• Bryan Chan, Huawei
• Shivarama Rao, AMD
• Gary Klimowicz

Gatekeepers are chosen based on their involvement in Flang development. If you would like to be a gatekeeper, please submit your request to flang-dev.

The process:

1. We use the #classic-flang-pull-requests channel on Slack to discuss which pull requests we would like to review.

2. Each pull request has an owner. The owner is typically the person who created the pull request; however, anyone may adopt a pull request. The owner is responsible for making sure the PR can be merged with master and for handling feedback during the review and testing process. The owner can signal that a patch is ready for review using flang-dev email or Slack #classic-flang-pull-requests.

3. As part of the review process, the reviewers agree to apply the patch and run their internal test suites with it, and give feedback on the patch. Note that feedback might be limited to simply pass or fail because of restrictions on the test suites.

4. Volunteer testers and reviewers offer feedback on the PR in the GitHub discussion on the pull request.

5. For all patches (with a few exceptions), at least two volunteers must apply the patch, run their internal tests, and give feedback on the patch. The patch should be tested on at least AArch64 and X86_64, on one of the supported LLVM versions. Exceptions include the following: (a) Only one review is required for CI changes, NFC non-code changes, testcases. (b) For Windows PRs two reviews (one from a Windows reviewer) are required and CI should pass.

6. When two reviewers complete their testing and approve the patch, a gatekeeper (usually one from the same organization as the patch owner) can merge the patch. Note that a gatekeeper is not mandated to merge a patch at this point if the discussion and consensus process has not run its course.

7. Reviewers who feel that they are not familiar with the subject matter of a pull request, or cannot give the PR proper attention in a timely manner, should remove themselves from the list of reviewers of the PR, or delegate the review request to another more knowledgeable person if possible.

8. If a patch has received one approval, but has waited for more than two weeks for a second approval, the owner can submit a motion, via email or Slack, to merge the patch with only one approval. If no further review comment is received within two weeks after the motion, a gatekeeper can merge the patch. This provision helps ensure that pull requests do not get stuck in the review process for too long.