THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Page History
...
- Attach a patch, pull request url or branch name (see instructions at Contribution waysWorkflow)
- Add comment describing what has been implemented.
- Move ticket to
PATCH AVAILABLEstate. - If there is a community member who you think should do the review, optionally assign the ticket to that person.
...
After development is finished, QA cycle starts, then release procedure follows.
Flow
Development Process
...
Mastershould become the development branch for the next release.- Whenever current release goes to QA,
...
- 1 major release per year
- multiple minor releases
- not every sprint is released (although it is better to try releasing every sprint)
Git Workflow
Mastershould 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 waymastercan be used to develop functionality of the next release. All release fixes get merged to release branch and then tomaster. - 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
masterbranch (or release branch if one exists - in this case changes get merged to release branch and then tomasterbranch). Changes get merged tomasterbranch of the project Git via process described at Contribution waysWorkflow. - 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, for example: ignite-1.3.0.
Normally, project repo should contain Normally, project repo should contain only master branch, very few branches for ongoing releases and commiter's branches ready to be reviewed. 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.
Release Process
Release Process
Instructions on how to build source and binary Instructions on how to build source and binary releases can be found at IGNITE_PROJECT_ROOT/DEVNOTES.txt. Please see Ignite Release Instructions section.
...
+-----------------+
...
Creation
To start:
- You need to fork an Apache Ignite mirror on GitHub.
- Make a local copy of your Apache Ignite mirror fork. Your remote origin will refer to 'https://github.com/<your_github_uname>/incubator-ignite.git'.
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 the following:
Code Block git pull upstream git checkout master
...
- Fix / implement JIRA ticket in your fork. Commit branch to origin (origin = your fork). It's recommended to develop IGNITE-xxx ticket at ignite-xxx branch.
- Create pull request from the new remote branch in the fork to master of Apache Ignite mirror. Please, start a title of the pull request from 'IGNITE-xxx'. An email about the pull request will be send to dev-list and the same JIRA comment will be added to the IGNITE-xxx ticket.
- TeamCity will automatically trigger builds and label it as a "pull/<pull-request-number>/head". Select this label in the branches dropdown and monitor test results.
- Once tests are passed, the pull request can be reviewed and merged by a committer.
...
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:
...
- Checks that you don't have any uncommitted changes.
- Checks you are one master branch and master branch is up-to-date.
- Updates local master from Apache git repo.
- Fetches pull request to a local branch:
git fetch upstream pull/<id>/head:pull-<id>-head- Saves an author and a comment of the last commit at pull-<id>-head.
- Merges from the new branch to master:
git merge --squash pull-<id>-head
- Ask you about custom comment or using the saved comment.
- 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
2. Create a Patch-file
...
Creation
You can start by cloning the Ignite GIT repo.
| Info | ||
|---|---|---|
| ||
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:
- Committers will not forget to give proper credit to a contributor
- Contributor's name and email address show up in the git log
...
| Info | ||||
|---|---|---|---|---|
| ||||
Note: All TC test builds can be triggered manually via "Ignite/ -> Run All for patch" (by 'Jira number'). A comment will be added to the jira with all new triggered builds. |
...
Applying
Contributor patches have to be applied by next command.
...
3. 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'ready to be reviewed' branch ignite-XXXX, where XXXX is the number of the JIRA ticket.
TeamCity should be forced to run all tests on created branch before review. Once tests are passed, the branch can be reviewed by another committer.
Created branch name should be attached to a JIRA ticket and the ticket status should be changed on Patch Available.
Branch can be merged to master on sucessful review by at least one another committer.
Branch should be deleted successful review and merging on branch merged to master or issue cancelled. Committers are in charge of deleting their branches.
Overview
Content Tools
Apps