IMPORTANT
The JIRA handling process outlined below should be followed in absolutely all cases, without exceptions, regardless of the ticket complexity.
IN PROGRESS
state.Master Branch
PATCH AVAILABLE
state.CLOSED
state. 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.
master
branch)Master
should become the development branch for the next release (current sprint).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
.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.master
(or release) branch.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 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.
TeamCity is used for Continuous Integration. It is located here - http://204.14.53.153/overview.html.
See How to Contribute page.
Instructions on how to build source and binary releases can be found at IGNITE_PROJECT_ROOT
/DEVNOTES.txt
. Please see Ignite Release Instructions
section.
There are 2 way how you can make contribution
+------------+ +---------------+ +-----------------+
| | replica | | fork | |
| Apache Git | ==========> | GitHub Mirror | ---------> | John Doe's Fork |
| | | | | |
+------------+ +---------------+ +-----------------+
^ ^ ^
| | |
| +------------------------+ | origin
| upstream | |
| | |
| +-----------------+
| *Apache Git remote handle for committers* | |
+------------------------------------------------| Local clone |
| |
+-----------------+
To start:
You will need to update a local master sometimes (to merge to your development branches sometimes). How to do it:
Add remote for Apache Ignite mirror (you need to do it once)
git remote add upstream https://github.com/apache/ignite.git
Each time when you want to update your local master do next:
git checkout master
git pull upstream
To make contribution:
In additional to contributors configuration, commiters need to have one more remote - for working with Apache Git repo. It can be added like this:
git remote add apache https://git-wip-us.apache.org/repos/asf/ignite
To push any branch at Apache repo use
git push apache <branch_name>
To apply a pull-request it's strongly recommended using ./scripts/apply-pull-request.sh script. Script takes 'pull-request-id' as a parameter and do next:
git fetch upstream pull/<id>/head:pull-<id>-head
git merge --squash pull-<id>-head
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
You can start by cloning the Ignite GIT repo.
Clone the repo
git clone https:
//git-wip-us
.apache.org
/repos/asf/incubator-ignite
We use git as our version control system. To streamline the process of giving proper credit to the contributors when committing patches, we encourage contributors to submit patches generated using "git format-patch"
command. This has many benefits:
Long story short, it makes both the contributors' and committers' lives easier, so please generate your patches using git format-patch
.
We have the following requirements for patches:
We prefer that you use the following step-by-step instructions when developing with Ignite.
For example, if you are starting working on the feature IGNITE-9999.
## Get the repo
git clone https://github.com/apache/incubator-ignite.git
## Some development here with many commits at ignite-9999.
git commit -a -m 'ignite-9999: Intermediate commit 1';
...
git commit -a -m 'ignite-9999: Intermediate commit 100';
## Commit the last changes.
git commit -a -m 'ignite-9999: Implemented.';
## Making patch.
## There are a lot of changes at ignite-sprint-999 and we need to get it, resolve conflicts (if exists), rerun tests for ignite-9999.
git checkout master
git pull
git checkout ignite-9999
git merge master
## Run script to make patch. Patch will have all changes as one commit.
<ignite_home>/scripts/git-format-patch.sh
Note: it is strongly recommended to merge 'master' branch to your development branch, for example, every day (or after each commit).
Created patch-file should be attached to a JIRA ticket and the ticket status should be changed on Patch Available.
If you do everything correctly, then all necessary TC test builds will be triggered automatically in 3 minutes period, and a comment with triggered build information (test package names, TC build links) will be added to the JIRA.
Requirements (to auto triggering the test builds):
Contributor patches have to be applied by next command.
git am -s <patch-file>
This command apply a patch file generated by 'git format-patch', stores information who created a patch and who applied a patch. So, it gives proper credit to the contributor and store an information who decide to take these changes.
If patch file has been created by scripts/git-format-patch.sh then a name of a patch-file contains a short hash revision of master branch revision against which patch has been created. Patch file template is
master_<hash>_ignite-<ticket-number>.patch
For example
master_b001525_ignite-9999.patch
So, in case, if a patch can't be applied without conflicts on the HEAD of master and the patch has been created by scripts/git-format-patch.sh then a commiter can apply the patch to master by a revision hash, review changes and resolve the conflicts by yourself.