Table of Contents |
---|
Apache Way, Apache Con (Slides)
...
Please start from sending out an introduction email to the project's dev mailing list (at first: subscribe) with a request for contributors permissions.
Info | |||
---|---|---|---|
| |||
Subject: I want to contribute to Apache ignite Hello, Everyone! My name is [ Name ]. I want to contribute to Ignite. I would like to start from [ identification of particular ticket or module, if you have one in mind ]. Please, help me to start contributing. My ASF JIRA username is [ username ]*. Regards, [ Name ] *learn more about ASF JIRA below |
The JIRA handling process outlined below should be followed in absolutely all cases, without exceptions, regardless of the ticket complexity. | ||
Info | ||
---|---|---|
| ||
New contributors should register account at If you do not have ASF JIRA account, use https://issuesselfserve.apache.org/jira/secure/Dashboard.jspa-account.html to request a new one before going to the next step. Once you have an ASF JIRA account, send out an introduction email to the project's dev mailing list (at first: subscribe) with a and send out email to project's dev list !!ссылка!! with request for contributors permissions. Committers PMCs should handle this request and grant contributor access to a new community member. |
Info | ||
---|---|---|
| ||
The JIRA handling process outlined below should be followed in absolutely all cases, without exceptions, regardless of the ticket complexity. |
Tickets are picked up by community members from a pool of unassigned and unscheduled tickets.
!!JIRA issues are grouped by fixVersion
field. Tickets should be assigned to an unreleased version if they are blockers or regressions for that version. Contributor The contributor should make sure that fixVersion
is set to a proper version that actually releases the changes made in the scope of the ticket. Open and in-progress tickets may have this field blank.!!
The following page contains information on upcoming releases: Release Planning.
IN PROGRESS
state.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.
...
Any change should be reviewed by a contributor and passed to a committer (who may or may not be the same as the main reviewer) for merging.
PATCH AVAILABLE
state.Info | ||
---|---|---|
| ||
Check affected files' git history to find a 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 below.
for example: "[~avinogradov], Please review my changes."
|
+------------+ +---------------+ +-----------------+
| | replica | | fork | |
| Apache Git | ==========> | GitHub Mirror | ---------> | John Doe's Fork |
| | | | | |
+------------+ +---------------+ +-----------------+
^ ^ ^
| | |
| +------------------------+ | origin
| upstream | |
| | |
| +-----------------+
| *Apache Git remote handle for committers* | |
+------------------------------------------------| Local clone |
| |
+-----------------+
To startSetting up:
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
Each time when you want to update your local master do the following:
Code Block |
---|
git pull upstream git checkout master |
To make contributionContributing:
Info | ||
---|---|---|
| ||
Note: Existing pull request requests should be updated instead of the creation of new oneones, when possible. |
In additional addition to contributors configuration, committers need to have one more remote repo - for working with Apache Git repo. It can be added like this:
...
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 the pull-request. Changes can be reviewed again. If you accept all changes and want to push it, do next:
git push apache master
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.
TeamCity should be forced to run all tests on created branch before review. Once tests are passed, the branch has be been reviewed by the module's maintainer.
Created branch name should be attached to a JIRA ticket and the ticket status should be changed on Patch Available.
Branch The branch can be merged to master on successful review by at least one another committer.
Branch The branch should be deleted on branch merged to master or issue cancelledcanceled. Committers are in charge of deleting their branches.
Component | Maintainers | |
---|---|---|
Ignite Core (the rest of internals not covered below) | ||
PME | ||
Rebalance | ||
Affinity | ||
PDS | ||
Encryption | ||
MVCC (obsolete) | ||
Transactions | ||
Snapshots | ||
Marshalling (Binary, Optimized, JDK) | ||
Discovery & Communication SPIs | ||
Ignite Compute API | ||
Ignite Services API | ||
Ignite SQL & Text Queries & JDBC | ||
Ignite Continuous Queries | ||
Machine Learning/Deep Learning (ml, TensorFlow, sub-modules in ml) | ||
Build System / Releases | ||
TeamCity Bot | ||
Spark Integration | ||
.NET API | ||
C++ API | ||
Other thin clients (Python, Node.js, PHP, etc) | ||
ODBC | ||
JDBC | ||
Streamers (JMS, Flume, Kafka, etc.) | ||
Docker, Mesos, YARN integration | ||
AWS, Google Compute Engine, JClouds integration | ||
Visor Console | ||
WebSession & WebSession Filter |