• Home
    • View
    • Login
    This page
    • Normal
    • Export PDF
    • Page Information

    Loading...
  1. Dashboard
  2. Undefined Space
  3. OpenJFX
  4. Code Reviews

Page History

Versions Compared

Old Version 29

changes.mady.by.user Kevin Rushforth

Saved on Oct 19, 2018

compared with

New Version 30

changes.mady.by.user Kevin Rushforth

Saved on Oct 19, 2018

  • Previous Change: Difference between versions 28 and 29
  • Next Change: Difference between versions 30 and 31
  • View Page History

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

All code must be reviewed before being pushed to the repository. The short version of the OpenJFX code review policy is:

  1. We define a formal "Reviewer" role, similar to the JDK project.

  2. The code review policies recognize the following different types of changes, with different thresholds for review:
    1. Simple, low-impact fixes: 1 Reviewer
    2. Higher-impact fixes: 2 Reviewers + allow sufficient time (1 day recommended) for others to chime in
    3. Features / API changes: CSR for approving the change, including approval by a "lead"; implementation then needs 2 Reviewers for the code (as with other "higher-impact" fixes above)

  3. A review can either be done via a webrev posted to http://cr.openjdk.java.net/ (with review comments in JBS or on the mailing list), an in-line diff in the bug report for tiny one or two line changes, or a fix developed in the GitHub sandbox and submitted via a pull request (with review comments in the PR itself). In the latter case, an email must be sent to openjfx-dev announcing the review, and all other review policies must be satisfied, before the PR is merged into the develop branch on GitHub. If so, the PR itself will serve as the review.

...

The review of the implementation follows the same "two reviewer" standard for higher-impact changes as described in category B. The two code reviewers for the implementation may or may not include the Lead who reviewed the CSR. The review / approval of the CSR is an independent step from the review / approval of the code change, although they can proceed in parallel.

3. Streamlined review process for changes developed on GitHub

A GitHub pull-request (PR) targeted to the 'develop' branch of the https://github.com/javafxports/openjdk-jfx repository can serve as the formal review for a fix, instead of a webrev, thus allowing it to be integrated into main line 'jfx-dev' HG repo without an additional review, provided all of the review policies are followed prior to merging the PR into the 'develop' branch. In particular:

...

Overview
Content Tools
ThemeBuilder

Terms of Use
• License: GPLv2
• Privacy • Trademarks • Contact Us

Powered by a free Atlassian Confluence Open Source Project License granted to https://www.atlassian.com/software/views/opensource-community-additional-license-offer. Evaluate Confluence today.

  • Kolekti ThemeBuilder Powered by Atlassian Confluence 8.5.21
  • Kolekti ThemeBuilder printed.by.atlassian.confluence
  • Report a bug
  • Atlassian News
Atlassian
Kolekti ThemeBuilder EngineAtlassian Confluence
{"serverDuration": 183, "requestCorrelationId": "8acd20a1ad4b2b10"}