JIRA Process

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.

Beginning Work

• Anyone in the community can start working on any unassigned ticket
• 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.

Commit Then Review (CTR)

• Ignite employs Commit-Then-Review (CTR) process.
• It is up to a committer to decide whether a change should need a review or not. 
• Any change that touches code or test, whether reviewed or not, must have full TeamCity CI test suite pass.
• As a guideline, trivial changes, like updates to documentation or tests, etc. should not need a review prior to committing, and often can be made directly in the master branch.
• It is strongly recommended to have non-trivial changes reviewed by at least one other committer.

Submitting For Review

• Create and attach a patch (see instructions here)
• Add comment describing what has been implemented.
• Move ticket to PATCH AVAILABLE state.
• If there is a community member who you think should do the review, optionally assign the ticket to that person.

Reviewing a Ticket

• Add review comments to a ticket.
• Assign to the community member working on this ticket.
• Once the comments have been addressed, the ticket should be submitted for review again.

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 CLOSED state. 

Git Process

Overview

Ignite development is split into 2 week sprints. However, duration may be longer or shorter. Preferably, each sprint should end with a public release.

After development is finished, QA cycle starts, then release procedure follows.

Flow

Development Process

• Iterative Sprints
  • new sprint every 2 weeks (development is in master branch)
  • 2 weeks development
  • 2 weeks testing (testing current sprint while developing next one)
    
    
• Releases
  • 1 major release per year
  • multiple minor releases
  • not every sprint is released (although it is better to try releasing every sprint)

Git Workflow

• Master should become the development branch for the next release (current sprint).
• Whenever current release (sprint) 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 patch validation process described here - How to Contribute.
• 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.

Git Branches

Each sprint development goes in master branch in project's git repo. At the moment build goes to QA release branch is created out of master: ignite-1.3.0.

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

Contributors should attach patch to JIRA issue and change issue's status to Patch Available.  After CI passes (http://204.14.53.153/overview.html), issue should be reassigned to committer for review and incorporation of the changes to sprint branch. See CI part below for more information about patch creation and patch validation. 

Committers may create a patch, a pull request, or create a branch ignite-1234, where 1234 is the number of the JIRA ticket.

JIRA Issues

JIRA issues are grouped by version field, which is an intended version of the product feature gets merged to.

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.

CI

TeamCity is used for Continuous Integration. It is located here - http://204.14.53.153/overview.html.

Patch creation

See How to Contribute page.

Release Process

Instructions on how to build source and binary releases can be found at IGNITE_PROJECT_ROOT/DEVNOTES.txt. Please see Ignite Release Instructions section.

Contribution ways

There are 2 way how you can make contribution

...