Versions Compared

Old Version 126

changes.mady.by.user Pavel Tupitsyn

Saved on

compared with

New Version Current

changes.mady.by.user Ilya Kasnacheev

Saved on

Key

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

Table of Contents

Apache Way

ASF: How It Works

ASF: The Apache Way

Apache Way, Apache Con (Slides) 

JIRA Process

Info
titleIMPORTANT

The JIRA handling process outlined below should be followed in absolutely all cases, without exceptions, regardless of the ticket complexity.

...

Info
titleJIRA Accounts

New contributors should register account at https://issues.apache.org/jira/secure/Dashboard.jspa and send out email to project's dev list with request for contributors permissions. Committers should handle this request and grant contributor access to new community member.

Getting Started

Tickets and Versions

Tickets are picked up by community members from a pool of unassigned and unscheduled tickets after discussion on project's dev list. Assigning tickets to a version contributor helps others to understand what will be included in next release.

...

The following page contains information on upcoming releases (draft) Release Plan.

Ticket Creation

  • Every JIRA ticket should be sufficiently described. 
  • There should not be any tickets with title only and without description. 
  • If there is a discussion pertaining to the ticket, the ticket should have a link to the dev list.

Working on a ticket

  • Anyone in the community can start working on any unassigned ticket. 
  • (OPTIONAL) It is recommended to clarify the relevance and correctness of the ticket in the community before doing actual implementation. To do this, you can write an email to the dev.list and wait for answer.
  • Before beginning working on a ticket, you should assign the ticket to yourself.
  • Move the ticket to IN PROGRESS state.
  • If necessary, add comments describing the design decisions or approach you plan to take.

Documenting a ticket

If the changes implemented under the ticket require changes in user documentation, create a related documentation ticket (add "Documentation" to the Component field) and provide a reasonable amount of details in the ticket's description. The information provided in the ticket should be sufficient for any contributor to start working on it. If there is no need to change user documentation, uncheck the Docs Required flag. The Docs Required flag is used to filter out the tickets that require documentation so that our documentation is always up to date.

Review Process and Maintainers

  • Ignite employs both Review-Then-Commit (RTC) process for most of the components and Commit-Then-Review (CTR) for few ones.
  • Please consult to Review Checklist to understand how tickets are reviewed and what rules to follow.

...

ComponentMaintainers
Ignite Core (the rest of internals not covered below)

Anton Vinogradov Alexey Goncharuk


PME

Pavel Kovalenko


Rebalance

Anton Vinogradov Pavel Kovalenko


AffinityPavel Kovalenko

PDS

Alexey Goncharuk


Encryption

Compression

MVCCIgor Seliverstov

Transactions

Alexey Scherbakov

Marshalling (Binary, Optimized, JDK)
Discovery & Communication SPIsAlexey Goncharuk
Ignite Compute API
Ignite Services API

Denis Mekhanikov Vyacheslav Daradur

Ignite SQL & Text Queries & JDBC

Iurii Gerzhedovich

Ignite Continuous Queries
Machine Learning/Deep Learning (ml, TensorFlow, sub-modules in ml)Alexey Zinoviev
Build System / ReleasesAnton Vinogradov
TeamCity Bot CTR*
Hadoop Accelerator
Spark Integration

Nikolay Izhikov Alexey Zinoviev

IGFS
.NET API

Pavel Tupitsyn 

C++ API

Igor Sapego

Other thin clients (Python, Node.js, PHP, etc)

Igor Sapego

ODBC

Igor Sapego

JDBC

Iurii Gerzhedovich

Streamers (JMS, Flume, Kafka, etc.) CTR*Saikat Maitra
Docker, Mesos, YARN integration
AWS, Google Compute Engine, JClouds integration
OSGi integration
Visor
WebSession & WebSession Filter

Submitting for Review

  • Attach pull request URL or branch name (see instructions at Workflow)
  • (OPTIONAL) create an Upsource review: Review With Upsource
  • Add comment describing what has been implemented.
  • Move ticket to PATCH AVAILABLE state.
Info
titleOptional: Tips to pass review quickly

Ask committer to review changes directly.


Check affected files git history to find person most likely able to review changes.

In case it's hard to determine who's able to review by git history use maintainers list presented above.


Add "review request" comment to the Jira Issue starting with a committer username.

for example: "[~avinogradov], Please review my changes."


committer will gain notification and review your changes and/or help to find another committer to do this.

Reviewing a Ticket

  • Make sure that your patch satisfies Review Checklist rules.
  • Each comment should be started with [~username] to guarantee proper notification.
  • committer should add comment like "Changes accepted and ready to be merged." once review successfully finished.
  • If the committer/contributor has proposals, it is recommended to add a comment in the ticket in addition to PR / CR comments referring proposals added. This helps other committers to identify that fix has something to improve.

Peer Review and LGTM

After a pull request goes through rounds of reviews and revisions, it will become ready for merge. A reviewer signals their approval either by a JIRA/Dev. List comment such as “Looks good to me!” (LGTM).

...

Exceptions to this rule are rare and made on a case-by-case basis. For example trivial change may be merged by committer without review.

Closing a Ticket

  • Once ticket has passed all the reviews and has no additional comments, a committer should apply the latest patch to the master branch.
  • A comment should be added to the ticket stating that the patch has been applied to master.
  • Move ticket to RESOLVED state. 

Review With Upsource

Upsource is an online code review tool. It provides a convenient way to view and discuss changes.

...

  • Follow the Upsource link in JIRA
  • Select files on the left to view changes
  • Click on line numbers to leave comments
  • Leave general comments on the timeline screen
  • Addressed comments may be marked as "Resolved"
  • When all issues are resolved (if any), click "Accept" on the top left, and leave a comment in JIRA

Git Process

Apache Ignite community agreed to release new version at least once per quarter. However, duration may be longer or shorter. After development of new functionality is finished, QA cycle starts, then release procedure follows.

Overview

  • Master should become the development branch for the next release.
  • Whenever current release goes to QA, new branch should be created from master. This way master can be used to develop functionality of the next release. All release fixes get merged to release branch and then to master.
  • All individual ticket/features development happen in separate repositories (either local or forks of GitHub mirror - https://github.com/apache/ignite) . Firm rule: ticket/feature branches should never be pushed to repo. 
  • Development  branches should be created off of the master branch (or release branch if one exists - in this case changes get merged to release branch and then to master branch). Changes get merged to master branch of the project Git via process described at Workflow.
  • Git tag should be created for every release.
  • All CI tests must pass before the merge of ticket branches to the master (or release) branch.

Normally, project repo should contain only master branch, very few branches for ongoing releases and committer's branches ready to be reviewed. Committers and PMC members are in charge to make everyone follow this rule.

Release Process

Instructions on how to build source and binary releases can be found at DEVNOTES.txt. Please see "Ignite Release Instructions" section. On how to make official release please refer to Release Process.

Workflow

There are several ways how you can make contribution

  • GitHub pull-request
  • Ticket Branch (only committers)

Create GitHub pull-request


 +------------+             +---------------+            +-----------------+

...

                                                         +-----------------+

Creation

To start:

...

Info
iconfalse

 Note: Existing pull request should be updated instead of creation of new one. Creation of more than one pull request for one issue forbidden.

Applying

In additional to contributors configuration, committers need to have one more remote reoi - for working with Apache Git repo. It can be added like this:

...

  1. Checks that you don't have any uncommitted changes.
  2. Checks you are one master branch and master branch is up-to-date.
  3. Updates local master from Apache git repo.
  4. Fetches pull request to a local branch:

    • git fetch upstream pull/<id>/head:pull-<id>-head

  5. Saves an author and a comment of the last commit at pull-<id>-head.
  6. Merges from the new branch to master:
    • git merge --squash pull-<id>-head
  7. Ask you about custom comment or using the saved comment.
  8. Commit to local master. The script automatically sign-off a commit and add "Fixes #<id>." suffix to comment (It will close the pull request, see https://help.github.com/articles/closing-issues-via-commit-messages/):
    • git commit --author=“<saved_author>" -s -m “<comment> - Fixes #<id>.”

Now, you will have one commit at master with all changes from pull-request. Changes can be reviewed again. If you accept all changes and want to push it, do next:

  •  git push apache master

Create a Ticket Branch (only committers)

Creation & Applying

Whenever working on bigger features, committers can also create 'ready to be reviewed' branch ignite-XXXX, where XXXX is the number of the JIRA ticket.

...

Branch should be deleted on branch merged to master or issue cancelled. Committers are in charge of deleting their branches.  


Checklist before push

List of points should be checked before push: 

Javadoc

Make sure project build log contains no javadoc warnings. Grep build output for "Javadoc Warnings". Covered by Licenses & Javadoc TeamCity task.

Readme

In case a new module is added, make sure it contains README.txt at the module's root.

Documentation & Examples

If the contribution is significant (new feature or significant rework of an existed functionality or API) make sure that an example is added to 'ignite-example' and/or an article is written for Apache Ignite Documentation.

Since readme.io does not automatically copy the changes from the current version to the subsequent version, documentation for any new feature that will be released in the next version should be created within the document for the current version. These new pages should be kept hidden until the next version released. 

Licenses

In case new module added, make sure source and binary distributions contains correct license files at modules folders. Covered by Licenses & Javadoc TeamCity task.

...

Code Block
mvn clean validate -DskipTests=true -P check-licenses

package-info.java

Make sure each package contains package-info.java with proper description.

Project Build

Make sure that command

Code Block
mvn clean package -DskipTests

...