Skip to content

Community

kiranchandramohan edited this page Mar 29, 2021 · 14 revisions

Mailing lists

We have an LLVM-sponsored flang-dev email list for Flang. This is used both for the LLVM flang and the "Classic" flang compiler:

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

To identify emails related to classic Flang, use

We have a flang-compiler channel on Slack. Here's 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:

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
//
//===----------------------------------------------------------------------===//

The Pull Request Process

The goal of the Flang Community Pull Request Process is to ensure that only well-tested patches are incorporated into the github.com/flang-compiler/flang master branch. Most Fortran tests, benchmarks, and applications are proprietary, and therefore are not part of the flang public test suite, and 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, Sourabh Singh Tomar, AMD, for X86_64 testing
  • Kiran Chandramohan, Pawel Osmialowski, Arm, for AArch64 testing
  • Bryan Chan, Huawei, for AArch64 testing
  • Xoviat, Adam Kallai, for Windows testing
  • Michal Paszta, Mobica/Arm

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 run on at least AArch64, X86_64 on one of the supported LLVM versions. Exceptions include the following, i. Only one review is required for CI changes, NFC non-code changes, testcases. ii. 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 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.

Clone this wiki locally